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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 9 May 2012 10:24:47 -0700
Message-ID: <CA+c2ei94iy9DHpwoM9aBoUVqNfr5K9SK1Uhi7cYY+TejWz3d0w@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Henri Sivonen <hsivonen@iki.fi>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
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.

/ Jonas

/ Jonas
Received on Wednesday, 9 May 2012 18:17:45 UTC

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