[d_k_f]

The custom element specification (section 4.13) deals mostly with the registration and usage details, but the general extensibility section earlier on covers the basic use case: https://html.spec.whatwg.org/multipage/infrastructure.html#e...

"User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and styling them according to CSS (for CSS processors), but not inferring any meaning from them."

[troupo]

Yes. It means they are not "custom elements". They are basically divs.

[xigoi]

Yes, they are basically divs, but with a semantic name. Which is exactly what we wanted to achieve.

[troupo]

It's quite literally not what we were trying to achieve.

[xigoi]

How else would you want custom elements to work?

[troupo]

What we're discussing are not custom elements. If you rename a div into <some-other-name>, it doesn't make that a custom element.

Very quite literally in the very literal sense of the word the only way to create actual custom elements is through javascript. There's no other way.

A sibling comment posted this link: https://codepen.io/dkoch-org/pen/yLwPVYG. And this is not custom elements. These are "elements unknown to the browser which will be treated in a neutral way making them indistinguishable from divs/spans". In the context of "preventing div/span soup" this does absolutely nothing. It's the same soup, just with longer names.

[globular-toast]

Defining them in js doesn't "do anything" either. I think the dispute here boils down to why you would prefer longer names over div/span everywhere. It doesn't make any difference to users, but can make it a lot easier for developers. That's the main reason to do it for me.

[joquarky]

More like span, since the default is inline

[troupo]

Ah. For some reason I misremembered that the default is block.