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: James Graham <jgraham@opera.com>
Date: Wed, 09 May 2012 10:16:52 +0200
Message-ID: <4FAA27F4.70302@opera.com>
To: public-webapps@w3.org
On 05/09/2012 09:52 AM, Henri Sivonen wrote:
> On Tue, Apr 24, 2012 at 6:39 AM, Rafael Weinstein<rafaelw@google.com>  wrote:
>> What doesn't appear to be controversial is the parser changes which
>> would allow the template element to have arbitrary top-level content
>> elements.
>
> It's not controversial as long as an HTML context is assumed.  I think
> it is still controversial for SVG and MathML elements that aren't
> wrapped in an<svg>  or<math>  element.
>
>> I'd like to propose that we add DocumentFragment.innerHTML which
>> parses markup into elements without a context element.
>
> Why should the programmer first create a document fragment and then
> set a property on it? Why not introduce four methods on Document that
> return a DocumentFragment: document.parseFragmentHTML (parses like
> <template>.innerHTML), document.parseFragementSVG (parses like
> <svg>.innerHTML), document.parseFragmentMathML (parses like
> <math>.innerHTML) and document.parseFragmentXML (parses like innerHTML
> in the XML mode without namespace context)? This would avoid magic for
> distinguishing HTML<a>  and SVG<a>.

I think introducing four seperate methodsWithLongNames on document is 
not creating an API that authors will actually use. Instead it would 
likely be wrapped in some less-verbose API with a single entry point and 
library-specific magic and regexp to determine which entry point to use. 
So I fear this solution may just be punting the problem to a higher 
layer, where it will be more inconsistently solved.
Received on Wednesday, 9 May 2012 08:17:25 GMT

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