On Fri, Mar 13, 2015 at 1:27 PM, Benjamin Lesh <bl...@netflix.com> wrote:
> I agree completely, Tab, but it's actually too late to stop forcing authors
> to think about namespaces, the fact I currently have to think about it is
> the source of this suggestion.

You have to think about it today *because we've failed to do things
correctly*.  That doesn't mean we can't fix it so you can continue to
blithely ignore namespaces, like you can otherwise do for everything
except the createElement*() functions.

> The merging of namespaces is the ideal solution, no doubt, but it's probably
> not a realistic solution in the short or even medium term. It's almost the
> equivalent of punting.  SVG and HTML differ too drastically to just combine
> them overnight, I suspect. Different types stored in properties, different
> APIs, etc.

On the API level this is completely unproblematic.  SVGElement is
already a subclass of Element; the namespace really isn't a big deal.

The compat issue is just with libraries that branch on the namespace
for some reason, and that might be what kills this.

Importantly, though, we don't have to merge namespaces to make
<template> work correctly.  SVG already resolved that <template>
inside of SVG *should* be the HTMLTemplateElement, not a brand new
<svg:template> element that acts identically.  The <template> element
itself already has special parsing rules that cause it to start in
particular parser modes, to correctly handle things like
<template><tr><td>foo</td></tr></template>; giving it some more rules
to correctly handle <template><circle></circle></template> isn't
difficult or unrealistic.  With that, users of <template> can just
ignore namespaces entirely, except for the corner case of
<template><a>text</a></template>, which'll get interpreted as the
<html:a> element rather than <svg:a>.  Namespace unification closes
this final gap; it's not needed for the rest.

> It would be far easier/quicker to add an attribute and deprecate it later
> than get the namespaces merged. At the very least, it would immediately
> provide authors something they could polyfill to solve this issue.

Deprecation doesn't remove things; every thing we add, we should
assume is permanent.

"Immediately" is a funny term to use when discussing standards.
Adding an attribute and having it be useful cross-browser isn't any
faster than adding to the special cases for SVG-in-<template>.


Reply via email to