[Joeri]

Custom elements are incredibly powerful. Not only do they have their own tag name for easy selecting from css without having to use a class, but by adding custom attributes (eg size=“large”) you can basically eliminate the need for css classes entirely. Combine that with attr() to put the attribute value anywhere in or around the element with pure css and plenty of interactive components can be built purely with css, no scripting required. You can even use the @media scripting block to add noscript behavior to custom elements from css.

And then you can register a javascript class with customElements.define to add more dynamic behavior, and the sky becomes the limit. Custom elements are like a hidden framework built right into the browser.

[creesch]

While I believe you are entirely right from a developer perspective. I do wonder if the same is true from a UX and more specifically accessibility perspective as the author in the article describes.

If you are unsure what I mean, from the article

> I show them that a span with an onclick-event might seem to be behaving like a link, but that there are many layers of UX missing when you look a bit closer: right-click on this span, and a generic context menu opens up. When on the other hand you right-click on a proper link like this one a specialised context menu opens, with all kinds of options that are specific to a link. And I show them that proper links show up when you ask your screen reader to list all the links on a page, yet spans with an onclick-event don’t. Moreover, a span doesn’t receive focus when you tab to it. And so on. My students see this and they get it. And they love the fact that by being lazy they get much more result.

[Joeri]

Accessibility will rely on correct use of landmarks [1] and aria attributes, as well as real links (like the article mentions). Custom elements can do that just fine, by either decorating them with aria attributes manually and placing them in or around landmark elements, or by having the JS side of the custom element take care of that automatically. The JS class can generate any necessary markup inside of the element to help make it accessible, just like a component built with a JS framework would, and by using shadow dom and slots this markup can wrap around the child elements (though I think it's best to try to avoid shadow dom, as it is quite a cumbersome API to deal with). UX is a bit of a similar story, any kind of UX can be achieved once you register a JS class for the custom element.

[1] https://developer.mozilla.org/en-US/blog/aria-accessibility-...

[lenkite]

I didn't know this was possible. I thought you were forced to use Javascript to define a custom element - this severely reduced its attractiveness. Why use JS for static UI ?

[emseetech]

I don't know why custom elements never became common knowledge. I've had PR's blocked by people convinced I was doing arcane black magic by using them.

But they've been worked this way for decades. Now they weren't officially added to the spec until browser support for v1 of custom components, but that was still back in 2016.

[CraigJPerry]

I didn’t know any of this.

I feel like a huge door just opened on an idle Saturday morning. I need to experiment to form some opinions.

Thank you & parent poster too.

[Joeri]

If you're interested in learning about this stuff, I recently made a website about it: https://plainvanillaweb.com/

[majoe]

This was recently posted to HN and I started to read it. I think your explanation for web components is the best I encountered so far.

[CraigJPerry]

That site is good - i might have missed it in your site but one thing I’ve run into with custom elements today is accessibility - testing with a screen reader has shown up lots of issues. Maybe custom elements aren’t perfect but they are handy.

[Joeri]

I'll add it to the todo list :)

[1oooqooq]

how every accessibility effort ends

[mbo]

this is a good article on styling with custom elements too: https://www.keithcirkel.co.uk/css-classes-considered-harmful...