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