Proposal: Allow custom elements to be in any namespace

[hfmanson]

In the current spec custom elements can only be in the namespace http://www.w3.org/1999/xhtml
and without using is="" derive from HTMLElement. It is desirable to have custom elements in other namespaces

• Create custom SVG elements in the SVG namespace which derive from SVGElement
• Create elements in your own namespace using XHTML which derive from Element

My proposal is to add a ‘namespace’ property to ElementDefinitionOptions to specify in which namespace the custom element should be placed. I created an issue before for Custom Elements v0.

Advantages

• Custom element name clashes will no longer occur
• If the namespace isn't a standard namespace (e.g. http://www.w3.org/1999/xhtml or http://www.w3.org/2000/svg) the dash requirement for new custom element tag names can be removed. Updated according to ExE-Boss
• Possible to implement polyfills for XML dialects such as XForms, MathML or X3D

References

"Distributed Extensibility: Finally Done Right?" in XML Prague 2014 proceedings
Are web components seriously not namespaced? on the w3c mailing list

Implementation

https://github.com/hfmanson/custom-elements/tree/namespace-aware is a fork that implements this feature. A live demo is at http://mansoft.nl/custom-elements/

This polyfill needs to be run on a browser that does not support Custom Elements natively, e.g. Microsoft Edge or Firefox 58.

[trusktr]

This is an interesting topic. It's completely worthy to note that someone can opt into making a UI entirely out of SVG, but then they're unfortunately out of luck if they want to use Web Components. It would be great to use Web Components with any type of element (just like we can use React/Angular/Vue with any type of elements).

Worth noting: Scoped Custom Element Registries can also solve some of the namespacing problems.

Maybe, with scoped Custom Element registries, there could be a feature to allow for Custom Elements to define which class that elements distributed into a shadow root are upgraded to. No idea how it'd work, but seems like that topic may lend to that area of discussion. ( @justinfagnani )

[jarek-foksa]

I second that. I'm making extensive use of v0 custom SVG elements in Boxy SVG to implement on-canvas editing controls. Encapsulated SVG components could be also useful when doing complex charts and diagrams.

[annevk]

We discussed this in Tokyo, there isn't much interest from implementers. And SVG generally isn't getting much attention, despite having loads of technical debt. And to really make use of this SVG would have to be able to use shadow roots too (and its layout model have to work with that too).

[bzbarsky]

Note that the original shadow DOM proposals did try to support this. Would be useful context to know why it was dropped. @dglazkov

[jarek-foksa]

@annevk As discussed here, the needed changes to the SVG layout model seem rather trivial. SVG 2 spec is already defining <use> elements using Shacow DOM model: https://svgwg.org/svg2-draft/struct.html#UseShadowTree.

@bzbarsky WebKit team did not want SVG support in v1 specs for the sake of simplicity and ease of implementation: #110 (comment). I don't recall them dismissing the idea altogether.

[bzbarsky]

@jarek-foksa Right, but what were the specific complications and difficulties associated with it? "simplicity" and "ease of implementation" suggests those existed, unless they're code for "don't even want to think about it".

[bzbarsky]

In particular, I think I kow what the issues were with supporting this in the initial shadow DOM setup (all sorts of complications around ensuring that the proto chain matched the element type created etc), but most if not all of those should be gone in the [HTMLConstructor] setup. I haven't had a chance to think through what issues, if any, remain, hence asking whether someone else already has.

[jarek-foksa]

@bzbarsky I'm not sure about the specifics, but I recall that initial implementation of custom SVG elements in Chromium was ridden with bugs and it took them like 2 years to make it fully usable. For example, the styles and IDs in the shadow DOM were not properly scoped, thus leaking to the global scope and causing naming clashes.

[bzbarsky]

Just to be clear, custom elements and shadow DOM are orthogonal in terms of both specification and implementation.

The problem you describe has to do with shadow DOM, and is going to be a problem for shadow DOM even if you only allow HTML elements to be shadow hosts, as long as you put SVG elements in the shadow tree. It seems completely unrelated to custom elements.