On 05/19/2014 12:46 PM, Daniel Kinzler wrote:
Am 19.05.2014 20:01, schrieb Gabriel Wicke:
On 05/19/2014 10:55 AM, Bartosz Dziewoński wrote:
I am kind of lost in this discussion, but let me just ask one question.
Won't all of the proposed solutions, other than the one of just not expanding transclusions that can't be expanded to wikitext, break the original and primary purpose of ExpandTemplates: providing valid parsable wikitext, for understanding by humans and for pasting back into articles in order to bypass transclusion limits?
Yup. But that's the case with <domparse>, while it's not the case with
<html> unless $wgRawHtml is true (which is impossible for publicly-editable wikis).
<html transclusion="{{T}}"> would work transparently. It would contain HTML, for direct use by the client, and could be passed back to the parser, which would ignore the HTML and execute the transclusion. It should be 100% compatible with existing clients (unless the look for verbatim "<html>" for some reason).
Currently <html> tags are escaped when $wgRawHtml is disabled. We could change the implementation to stop doing so *iff* the transclusion parameter is supplied, but IMO that would be fairly unexpected and inconsistent behavior.
I feel that Parsoid should be using a separate API for whatever it's doing with the wikitext. I'm sure that would give you more flexibility with internal design as well.
We are moving towards that, but will still need to support unbalanced transclusions for a while.
But for HTML based transclusions you could ignore that - you could already resolve these using a separate API call, if needed.
Yes, and they are going to be the common case once we have marked up the exceptions with tags like <domparse>. As you correctly pointed out, inline tags are primarily needed for expandtemplates calls on compound content, which we need to do as long as we support unbalanced templates. We can't know a priori whether some transclusions in turn transclude special HTML content.
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.
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.
The use of <domparse> to mark up special HTML transclusions in expandtemplates output will be temporary (until HTML transclusions are the default), but even if such output is pasted into the actual wikitext it would be harmless, and would work as expected.
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. Wrapping such transclusions in <domparse> tags on the other hand normally does not entail any escaping, as only nested <domparse> tags are problematic.
Parsoid would keep working as before: it would treat <html> as a tag extension (it does that, right?)
$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.
Gabriel