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: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 10 May 2012 23:56:29 +0200
Message-ID: <CAAWBYDDjO1duCL4uXKzbP_pJriJgLNY4WrU3MB1F2O7kO=9mfQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Anne van Kesteren <annevk@annevk.nl>, Yehuda Katz <wycats@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Henri Sivonen <hsivonen@iki.fi>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>
On Thu, May 10, 2012 at 11:20 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 10 May 2012, Tab Atkins Jr. wrote:
>> Still, requiring an explicit context declaration *at all* defeats most
>> of the purpose of the API.  Again, if we don't auto-detect SVG (so that
>> "<rect>" just parses as HTMLUnknownElement by default), we haven't
>> gained much, since authors will *still* have to wrap their code in a
>> regex-based detector if they expect to ever use SVG.  (An optional
>> context declaration that lets you determine which way the tagname
>> conflicts go is fine, of course.)
> Can you elaborate on the use case for parsing markup into a document
> fragment when you don't know where you'll be putting the document fragment
> or what kind of content is in it?

That's pretty much exactly the description of the jQuery $("[markup
goes here]") functionality, which has been cited multiple times as the
justification for this functionality.  A previous thread about this
functionality was started by Yehuda Katz from jQuery about that exact
function, asking for this functionality.

Received on Thursday, 10 May 2012 21:57:19 UTC

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