Am 19.05.2014 23:05, schrieb Gabriel Wicke:
I think we have agreement that some kind of tag is still needed. The main point still under discussion is on which tag to use, and how to implement this tag in the parser.
Indeed.
Originally, <domparse> was conceived to be used in actual page content to wrap wikitext that is supposed to be parsed to a balanced DOM *as a unit* rather than transclusion by transclusion. Once unbalanced compound transclusion content is wrapped in <domparse> tags (manually or via bots using Parsoid info), we can start to enforce nesting of all other transclusions by default. This will make editing safer and more accurate, and improve performance by letting us reuse expansions and avoid re-rendering the entire page during refreshLinks. See https://bugzilla.wikimedia.org/show_bug.cgi?id=55524 for more background.
Ah, I though you just pulled that out of your hat :)
My main reason for recycling the <html> tag was to not introduce a new tag extension. <domparse> may occur verbatim in existing wikitext, and would break when the tag is introduces.
Other than that, I'm find with outputting whatever tag you like for the transclusion. Implementing the tag is something else, though - I could implement it so it will work for HTML transclusion, but I'm not sure I understand the original domparse stuff well enough to get that right. Would domparse be in core, btw?
Now back to the syntax. Encoding complex transclusions in a HTML parameter would be rather cumbersome, and would entail a lot of attribute-specific escaping.
Why would it involve any escaping? It should be handled as a tag extension, like any other.
$wgRawHtml is disabled in all wikis we are currently interested in. MediaWiki does properly report the <html> extension tag from siteinfo when $wgRawHtml is enabled, so it ought to work with Parsoid for private wikis. It will be harder to support the <html transclusion="<transclusions>"></html> exception.
I should try what expandtemplates does with <html> with $wgRawHtml enabled. Nothing, probably. It will just come back containing raw HTML. Which would be fine, I think.
By the way: once we agree on a mechanism, it would be trivial to use the same mechanism for special page transclusion. My patch actually already covers that. Do you agree that this is the Right Thing? It's just transclusion of HTML content, after all.
-- daniel