- 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