[emseetech]

It is perfectly reasonable and accepted html to use custom element names. Any element with a `-` is styled like a span by default.

  <article-content>
    <author-byline><author-byline>
    <content-text></content-text>
  </article-content>

This has the benefit that you can describe your markup however you'd like if it doesn't fit into the standard elements, and if you find yourself in "div soup", often times this is mitigated through class names, but using custom elements, the closing tags are much more readable than

      </div>
    </div>
  </div>

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

[arcanemachiner]

Wait... I can just declare one of these in HTML without doing all the CustomElement JS jiggery-pokery?

[xigoi]

No need to declare anything, just use the tag.

[simultsop]

Sounds like you did not jump into the pool of flexibility and reusability.

[lelanthran]

> Sounds like you did not jump into the pool of flexibility and reusability.

Quite a good analogy: a pool is responsible for more drownings than you'd think.

Most people in the pool of flexibility and reusability are drowning in it.

[_heimdall]

This would be way more helpful if browsers all supported extending built-in elements and inheriting accessibility features.

For example, if `class DropdownMenu extends HTMLSelectElement` worked, you could have full control of styling and functionality without having to recreate all the a11y support baked into `<select>`. As it stands today, this will be treated as a div and its all on you to make it accessible.

[Joeri]

Safari (Webkit) is the hold-out on having this: https://caniuse.com/mdn-api_customelementregistry_builtin_el...

The reasoning for choosing not to support it is here: https://github.com/WebKit/standards-positions/issues/97#issu...

[_heimdall]

Thanks! I was pretty sure Safari was the only major holdout but didn't have a link handy and didn't want to speak out of turn there.

That kind of support is a really tough one to work around with a major browser lacking support. For certain features its not a big deal, but when it comes to extending to get full accessibility support the only substitute is avoiding the feature and rolling it all custom. It really is a shame in my opinion, extending built-ins is extremely powerful.

[extra88]

Blame Safari. The standard includes the `is` attribute, it's supported by all browsers except Safari, but Safari not only hasn't worked on supporting it, they've stated they won't do so.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

[jillesvangurp]

Interesting, I did not know this was a thing. I just gave it a try and it seems to work as advertised. I'm definitely going to use that more. Div soup is super hard to untangle when you are debugging layout issues and I love having more readable html

[polydevil]

It is the same div soup for a screen reader, because there is no behavior attached to those new tags. They can not be a landmark, there are not marked as headings, they have no roles. Just a container with a text. And to attach the behavior you need to use javascript. So without js it wont work.

Why bother and try yo create half-baked non working solution if you can just use html?

Well, it easier to style, maybe. But hey, there is a class attribute.

[emseetech]

Custom elements are for when semantic elements run out, don't apply or are unnecessary.

Semantic elements are always preferred.