On Tue, Apr 24, 2012 at 6:39 AM, Rafael Weinstein <rafa...@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>. On Thu, Apr 26, 2012 at 8:23 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > (In my dreams, we just merge SVG into the HTML namespace, and then > this step disappears.) In retrospect, it would have been great if Namespaces in XML had never been introduced and SVG, MathML and HTML shared a single namespace. However, at this point trying to merge the namespaces would lead to chameleon namespaces which are evil and more trouble than fixing the historical mistake is worth. I feel very strongly that vendors and the W3C should stay away from turning SVG into a chameleon namespace. SVG is way more established them CSS gradients or Flexbox in terms of what kind of changes are acceptable. See http://lists.w3.org/Archives/Public/www-archive/2009Feb/0065.html as well as various XML experiences from non-browser contexts. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/