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