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