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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
