Re: template namespace attribute proposal

> 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 <annevk@annevk.nl> wrote:

> On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein <adamk@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/
>