[troupo]

You... Can't. You literally cannot define a custom element without Javascript.

[globular-toast]

You don't have to define it, though. Browsers are supposed to just put unknown elements in the DOM and style them like any other element, using CSS.

[mapreduce]

Is this behavior specified by the standard? Any links to the relevant section?

[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.

[joquarky]

More like span, since the default is inline

[troupo]

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

[joquarky]

You don't need a standard if it works in most browsers. And that's worked fine for me on nearly a dozen enterprise web apps since ~1995

[d_k_f]

Like I said: If you want to use the JS-based functionality, you obviously have to register it. Simply using any made-up element in your HTML and styling it via CSS just works ouf the box. See https://codepen.io/dkoch-org/pen/yLwPVYG for a quick example.

[troupo]

How exactly is this different from "the 'div/span-tag soup' as he calls it"? You just renamed some divs, and relied on the standardised behaviour of unknown tags. They are indistinguishable (and just as non-componentised and non-reusable) as the div/span soup.

[globular-toast]

How is `def reduce(numerator, denominator)` different from `def f(a, b)`?