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.

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.

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.
On Mar 13, 2015 1:16 PM, "Tab Atkins Jr." <jackalm...@gmail.com> wrote:

> On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren <ann...@annevk.nl>
> wrote:
> > On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh <bl...@netflix.com>
> wrote:
> >> What are your thoughts on this idea?
> >
> > I think it would be more natural (HTML-parser-wise) if we
> > special-cased SVG elements, similar to how e.g. table elements are
> > special-cased today. A lot of <template>-parsing logic is set up so
> > that things work without special effort.
> Absolutely.  Forcing authors to write, or even *think* about,
> namespaces in HTML is a complete usability failure, and utterly
> unnecessary.  The only conflicts in the namespaces are <font>
> (deprecated in SVG2), <script> and <style> (harmonizing with HTML so
> there's no difference), and <a> (attempting to harmonize API surface).
> If you just looked at the root element, skipping through <a>s, you
> could do the same magical mode selection we currently do for <tr>/etc.
> Ideally we could do this by just pulling SVG into the HTML namespace,
> which the SVGWG is comfortable with, but no implementors have felt
> like doing it yet. :/
> ~TJ

Reply via email to