On 05/09/2012 10:16 AM, James Graham wrote:
On 05/09/2012 09:52 AM, Henri Sivonen wrote:
On Tue, Apr 24, 2012 at 6:39 AM, Rafael Weinstein<[email protected]>
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.
By way of a concrete-strawman (or whatever it is one is supposed to say)
proposal:
document.parse(string, ["auto"|"html"|"svg"|"mathml"|"xml"])
With "auto" being the default and doing magic, and the other options
allowing one to disable the magic.
