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

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.   `._.-(,_..'--(,_..'`-.;.'