- From: Rafael Weinstein <rafaelw@google.com>
- Date: Wed, 9 May 2012 09:45:19 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
I'm very much of a like mike with Henri here, in that I'm frustrated with the situation we're currently in WRT SVG & MathML & parsing foreign content in HTML, etc... In particular, I'm tempted to feel like SVG and MathML made this bed for themselves and they should now have to sleep in it. However, on balance, I'm in favor of this "magic" (picking the correct namespace based on the first element's tagName) for the following three reasons: *Not doing so means that using <template> to declare web components that do super awesome SVG stuff much more cumbersome. *Doing so doesn't negatively impact HTML. *SVG mostly working (modulo a few overlapping tagNames), is preferable to not working at all (and there's not really a problem with MathML). Much as I dislike it, parsing foreign content is kind of already gross magic, and it seems to me like this behavior is in keeping with what's already there. Moreover, not including it kind of punishes the wrong people, by making webdevs sleep in the bed that SVG and MathML made. I.e. It would make my life easier, but at the expense of webdevs. On Wed, May 9, 2012 at 12:52 AM, Henri Sivonen <hsivonen@iki.fi> 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>. > > On Thu, Apr 26, 2012 at 8:23 PM, Tab Atkins Jr. <jackalmage@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 > hsivonen@iki.fi > http://hsivonen.iki.fi/
Received on Wednesday, 9 May 2012 16:45:56 UTC