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.

[jarek-foksa]

@bzbarsky Yeah, I was assuming that custom SVG elements would make sense only with shadow DOM support as mentioned by Anne. Anyway, in Chromium most issues with ID and style scoping were specific to SVG shadow trees, for example: https://bugs.chromium.org/p/chromium/issues/detail?id=424598

[hayatoito]

SVG 2 spec is already defining elements using Shacow DOM model: https://svgwg.org/svg2-draft/struct.html#UseShadowTree.

That would be just a sort of the implementation detail, and we should be careful not to make a decision based on that.

We should ask and clarify the intention why SVG is trying to use Shadow DOM as an implementation of <use> there.
I guess that is just the result of spec-ing how Blink is implementing SVG's <use>, where there is no other intention.

[gertcuykens]

Hmm is this the proposal that would also make is work for class SvgIcon extends SVGElement ?

      import {html, render} from 'https://unpkg.com/lit-html?module'
      import SvgIcon from './SvgIcon.js'
      customElements.define('svg-icon', SvgIcon, {extends: 'svg'})
      render(html`
        <svg is="svg-icon" viewBox="0 0 75 75" icon="add"></svg>
        `, document.body)

Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': "svg" is an HTMLUnknownElement

[ExE-Boss]

@gertcuykens It should.

@hfmanson

If the namespace isn't used by the browser for rendering (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.

Maybe keep the dash restriction for official w3c namespaces.

This is also because MathML elements are all implemented using just the Element interface (there’s no MathMLElement WebIDL interface and rendering is handled via custom appearance and display values).

[bkardell]

@ExE-Boss note we are interested in improving the idl situation here https://github.com/mathml-refresh/mathml/issues/83

[justinfagnani]

I recently noticed that SVG2 specs the behavior of unknown tags to act like <g>: https://www.w3.org/TR/SVG2/struct.html#UnknownElement

The problem is no browser implements this. If they did, we would be able to "polyfill" custom SVG elements much like we do with HTML custom elements.

[trusktr]

Another question is, if we have custom SVG elements (as awesome as it would be for developers making things with better-organized SVG code), then we export the DOM as HTML and throw it at applications like Adobe Illustrator or Inkscape, what is supposed to happen?

[akauppi]

@trusktr I don't think that would be a problem. Either renderers ignore them altogether (as happens today, with unknown SVG elements in browsers), or they treat them as g if SVG2 is followed (see @justinfagnani 's message above).

So to me, this seems a non-concern. Any HTML/XML is intended to be expandable, so nothing new there.

[justinfagnani]

Is there anything we could do to get movement on allowing SVG custom elements? There are some very large unaddressed use cases here for charting, dynamic illustrations, drawing apps, very graphical UIs like node/edge editors, etc. Any chance SVG is in a better maintained state since 2018?