Perhaps the spec could be simplified (removing mentions of extending SVGElement, prototype chain walking for that, removing mention of an unknown interface for XML elements, etc.)

FWIW here is an example of using type extensions with SVG, which seems to work fine and dandy:

<http://jsbin.com/elivaz/2/>

However Blink may not be spec compliant in some way that makes this possible while it is disallowed by the spec.

I think it is fine for SVG Custom Elements to always be type extensions. What would you draw, otherwise?

(In reply to comment #2)
> However Blink may not be spec compliant in some way that makes this possible
> while it is disallowed by the spec.

The question in the bug is much simpler: should declarative syntax support anything other than HTML namespace?

(In reply to comment #3)
> The question in the bug is much simpler: should declarative syntax support
> anything other than HTML namespace?

Yes.

An observation:

It doesn't make sense for SVG Custom Elements to be custom tags. They should be type extensions.

Therefore the "extends" attribute unambiguously indicates whether a custom element is an SVG element. (There's no overlap between SVG and HTML tag names, right?)

(In reply to comment #4)
 
> Therefore the "extends" attribute unambiguously indicates whether a custom
> element is an SVG element. (There's no overlap between SVG and HTML tag
> names, right?)

script and style, to name a few :-\

(In reply to comment #5)
> (In reply to comment #4)
>  
> > Therefore the "extends" attribute unambiguously indicates whether a custom
> > element is an SVG element. (There's no overlap between SVG and HTML tag
> > names, right?)
> 
> script and style, to name a few :-\

That sucks. Namespace attribute, which defaults to HTML's?

(In reply to comment #6)
> That sucks. Namespace attribute, which defaults to HTML's?

Let's tackle this later.