Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

Yehuda Katz
(ph) 718.877.1325


On Wed, May 9, 2012 at 10:24 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, May 9, 2012 at 10:01 AM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > Quick alternative proposal that might work for both <template> parsing
> and
> > DocumentFragment.innerHTML:
> >
> >   Have createDocumentFragment() take as an argument a context element.
> >   Maybe also make it a mutable attribute of the object. Defaults to its
> >   owner document's body element or root element or some such. Null means
> >   no root element.
> >
> >     var df = document.createDocumentFragment(document.body);
> >     df.contextElement = document.createElement('style');
> >
> >   Have innerHTML use that as the context element to the fragment parsing
> >   algorithm.
> >
> >     df.innerHTML = 'p::before { content: '<hello> <world>'; }';
> >
> >   Have <template> take an argument that's the element tag name for it to
> >   use to create its context element. Defaults to <body>.
> >
> >     <template context="tr"> <td> </template>
> >     <template context="svg"> <g/> </template>
> >
> >   Parse <template> by creating a new Document object that's like the ones
> >   you get from createDocument() (i.e. "dead"), and then creating a
> >   DocumentFragment owned by that Document, and then pushing that
> >   DocumentFragment onto the stack instead of the <template> element, but
> >   set up to act like the <template> element for the purposes of being
> >   popped off. (Except when parsing without a browsing context, then you
> >   just parse normally.)
> >
> > Not sure how solid this is, but it's an idea at least. Hopefully an
> > original one, though I'm sure y'all have considered it before. :-)
>
> I think having to provide a context every where where you want to
> parse HTML is creating very bad developer ergonomics. As others have
> pointed out, it will likely just lead to developers ignoring these new
> APIs and continue to write their own parsing algorithms.
>
> I think it's much better to prioritize developers over implementers
> here and let implementers and spec writers tackle the complexity that
> comes with context-free parsing. I think the proposals here, and the
> fact that jQuery has implemented context-free HTML parsing, proves
> that it is technically possible.
>

I agree. It also illustrates that the idea of the API is intuitively
understood by developers.


> / Jonas
>
> / Jonas
>

Received on Wednesday, 9 May 2012 18:15:10 UTC