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: Scott González <scott.gonzalez@gmail.com>
Date: Thu, 10 May 2012 18:24:37 -0400
Message-ID: <CAO8i3ieRmwEMRK-7CB4VQESBcJM9rQ046KOW4Pe7Pd3XMYuZoA@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, 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>
Why is simplicity not enough of an answer?

If you're developing a widget which uses templates for various portions,
then as the widget developer you won't know the context for each template.
You could probably figure it out by rendering the templates from top to
bottom and inspecting the element where the next template will be inserted,
but that's unnecessary work if the browser can do it for us. Alternatively,
you can ask the user to provide the context, but then your widget API goes
from simple strings to either hashes or arrays.


On Thu, May 10, 2012 at 6:18 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 10 May 2012, Tab Atkins Jr. wrote:
> > 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.
>
> Yes, I understand that. But what's the use case?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Thursday, 10 May 2012 22:25:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT