- From: James Graham <jgraham@opera.com>
- Date: Wed, 09 May 2012 10:16:52 +0200
- 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 UTC