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).
I'll have to re-read Gabriel's <domparse> proposal tomorrow - right now, I
don't
see why it would be necessary, or how it would improve the situation.
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.
But still - I do not see why that would be necessary. If expandtemplates returns
<html transclusion="{{T}}">, clients can pass that back to the parser
safely, or
use the contained HTML directly, safely.
Parsoid would keep working as before: it would treat <html> as a tag extension
(it does that, right?) and pass it back to the parser (which would expand it
again, this time fully, if action=parse is used). If parsoid knows about the
special properties of <html>, it could just use the contents verbatim - I see no
reason why that would be any more unsafe as any other HTML returned by the parser.
But perhaps I'm missing something obvious. I'll re-read the proposal tomorrow.
-- daniel