Thanks all for the imput!
Am 14.05.2014 10:17, schrieb Gabriel Wicke:> On 05/13/2014 05:37 PM, Daniel Kinzler wrote:
It sounds like this won't work well with current Parsoid. We are using action=expandtemplates for the preprocessing of transclusions, and then parse the contents using Parsoid. The content is finally passed through the sanitizer to keep XSS at bay.
This means that HTML returned from the preprocessor needs to be valid in wikitext to avoid being stripped out by the sanitizer. Maybe that's actually possible, but my impression is that you are shooting for something that's closer to the behavior of a tag extension. Those already bypass the sanitizer, so would be less troublesome in the short term.
Yes. Just treat <html>...</html> like a tag extension, and it should work fine. Do you see any problems with that?
So it is important to think of renderers as services, so that they are usable from the content API and Parsoid. For existing PHP code this could even be action=parse, but for new renderers without a need or desire to tie themselves to MediaWiki internals I'd recommend to think of them as their own service. This can also make them more attractive to third party contributors from outside the MediaWiki world, as has for example recently happened with Mathoid.
True, but that has little to do with my patch. It just means that 3rd party Content objects should preferably implement getHtml() by calling out to a service object.
Am 13.05.2014 21:38, schrieb Brad Jorsch (Anomie):
To avoid the wikitext mangling, you could wrap it in some tag that works like <html> if $wgRawHtml is set and <pre> otherwise.
But <pre> will result in *escaped* HTML. That's just another kind of mangling. It's at all the "normal" result of parsing.
Basically, the <html> mode is for expandtemplates only, and not intended to be follow up by "actual" parsing.
Am 13.05.2014 21:38, schrieb Brad Jorsch (Anomie):
Or one step further, maybe a tag <foo wikitext="{{P}}">html goes here</foo> that parses just as {{P}} does (and ignores "html goes here" entirely), which preserves the property that the output of expandtemplates will mostly work when passed back to the parser.
Hm... that's an interesting idea, I'll think about it!
Btw, just so this is mentioned somewhere: it would be very easy to simply not expand such templates at all in expandtemplates mode, keeping them as {{T}} or [[T]].
Am 14.05.2014 00:11, schrieb Matthew Flaschen:
From working with Dan on this, the main issue is the ResourceLoader module that the diagrams require (it uses a JavaScript library called Vega, plus a couple supporting libraries, and simple MW setup code).
The container element that it needs can be as simple as:
<div data-something="..."></div>
which is actually valid wikitext.
So, there is no server side rendering at all? It's all done using JS on the client? Ok then, HTML transclusion isn't the solution.
Can you outline how RL modules would be handled in the transclusion scenario?
The current patch does not really address that problem, I'm afraid. I can think of two solutions:
* Create an SyntheticHtmlContent class that would hold meta info about modules etc, just like ParserOutput - perhaps it would just contain a ParserOutput object. And an equvalent SyntheticWikitextContent class, perhaps. That would allow us to pass such meta-info around as needed.
* Move the entire logic for HTML based transclusion into the wikitext parser, where it can just call getParserOutput() on the respective Content object. We would then no longer need the generic infrastructure for HTML transclusion. Maybe that would be a better solution in the end.
Hm... yes, I should make an alternative patch using that approach, so we can compare.
Thanks for your input! -- daniel