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