On Wed, May 9, 2012 at 10:16 AM, James Graham <[email protected]> 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.
Yes. In short, while making it Just Work for HTML is a great step, if you *still* need to use regex to tell when you're trying to build SVG so you can change the context, we aren't actually gaining much. ~TJ
