> So much of the rest of how SVG/MathML are handled in HTML is seamless by design. For my part, I disagree slightly with this statement. If you just drop a <circle> tag in a <div>, you're going to get an HTMLUnknownElement. This is by design and to spec, of course. But it unfortunately means you can't clone() the element over to an SVG parent and hope it will work. This was a problem in Angular's $compile that I helped sort out. Angular would simple clone() partials straight from the DOM and insert them, if that partial happened to be some fragment of SVG, you were then sticking HTMLUnknownElements in your SVG Doc. Ultimately, Angular ended up tracking namespace changes as it traversed the DOM looking for directives, as well as specifying a starting namespace for directives with template strings that were SVG partials.
Ember and Handlebars had similar issues with this. Handlebars had to use a wrapMap technique to create DOM elements in the proper way, but that didn't account for the <a> tag which exists in both namespaces. I'm not sure what HTMLBars is doing to solve this problem, honestly. I'd be shocked if whatever they were doing didn't require some sort of namespace specification somewhere, or simply didn't work with certain edge cases like the <a> tag. I think this feature is really something that will help framework developers and component library developers create generic code to accommodate their needs. It's more for code sanity than anything. <template><svg><circle/></svg></template> will clearly work, but then you're putting the onus on the framework authors to make conditional checks that might not always be accurate "is the firstElementNode svg?" If I'm a framework author, I can't dependably check that and just assume it's an SVG partial. It could be a full SVG-based web component. On Thu, Mar 12, 2015 at 2:08 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein <ad...@chromium.org> wrote: > > Is your thinking that adding special-casing for SVG-"looking" (as in, tag > > names appearing in the list of SVG tags but not in the list of HTML tags) > > inside <template> has fewer compat risks than a wholesale change of the > HTML > > parser to recognize SVG-looking tags anywhere? > > It was more principled, not sure about compatibility. Most of the HTML > parser depends on modes. Then requiring <svg> makes sense. Just like > it "makes sense" to require <table> for <td> not to be dropped. > However, <template> was designed to work with any element, > irrespective of mode. So <td> should work without <table> anywhere. > Following that logic, it would make sense if <circle> worked without > <svg> anywhere. > > > -- > https://annevankesteren.nl/ >
