W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

From: Rafael Weinstein <rafaelw@google.com>
Date: Fri, 11 May 2012 12:14:22 -0700
Message-ID: <CABMdHiTbN+yAcjL_-FY8-oZ4A+DeVVhg4wCKNwe_6upL3ShcKw@mail.gmail.com>
To: Webapps WG <public-webapps@w3.org>
Cc: Henri Sivonen <hsivonen@iki.fi>, "Tab Atkins Jr." <jackalmage@gmail.com>, Yehuda Katz <wycats@gmail.com>, Scott González <scott.gonzalez@gmail.com>
Ok, so I have some preferences, but they are *mild* preferences and
any permutation of the options below is acceptable to me.

On Fri, May 11, 2012 at 12:04 PM, Rafael Weinstein <rafaelw@google.com> wrote:
> Ok,
> So from the previous threads, there are appear to be three issues to
> resolve, and I'll list the options that I've noted.
> I'll follow up with my perspective of pros/cons and ask others to do
> the same. Please point out options or issues that I've missed.
> --------
> Issue 1: How to handle tokens which precede the first start tag
> Options:
> a) Queue them, and then later run them through tree construction once
> the implied context element has been picked

I like option (a) because you always get identical output for any
input relative to if you had applied it via innerHTML to the
appropriate implied context element. E.g.

myHTMLElement.innerHTML = "foo<body>bar";
myDocumentFragment.innerHTML = "foo<body>bar";

myHTMLElement.innerHTML == myDocumentFragment.innerHTML; // true;

Also, most browsers are already speculatively tokenizing ahead for
resource preloading purposes, so the implementation complexity isn't
especially daunting.

> b) Create a new insertion like "waiting for context element", which
> probably ignores end tags and doctype and inserts character tokens and
> comments. Once the implied context element is picked, reset the
> insertion mode appropriately, and procede normally.
> -------
> Issue 2: How to infer a non-HTML implied context element
> Options:
> a) By tagName alone. When multiple namespaces match, prefer HTML, and
> then either SVG or MathML (possibly on a per-tagName basis)
> b) Also inspect attributes for tagNames which may be in multiple namespaces
> c) Allow for inline name spacing of elements which would normally
> inherit the proper namespace from <svg> or <math>
> d) Somewhat orthogonal, but later allow for <template> to have an
> optional context attribute (e.g. <template context="svg">), which
> explicitly picks a context element.
> e) Some combination of the above.

I have a mild preference for not getting to fancy here. I'll mostly
stay out of this and let those who know more about SVG and MathML sort
it out, but I'll just note that the main concern cited for needing
this to work is with web components, and there I think Hixie's idea of
a declarative context element (e.g. option (d)) above is a nice
addition and might alleviate the need to get fancy.

> -------
> Issue 3: What form does the API take
> a) Document.innerHTML
> b) document.parse()
> c) document.createDocumentFragment()

I'm torn here between (a) & (b). I like the familiarity of (a), but
agree with Henri's point of about the namespace of the owner document
being a downside. I don't like (c) for stylistic reasons.
Received on Friday, 11 May 2012 19:14:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC