Custom tags for readability is one of those ideas which sound good in theory but stupid in practice.

Think `<readable-code>`, get a Slack thread where three seniors debate whether it's `<user-profile-card>` or `<profile-card-user>` while the shipper quietly ships it with `<div class="card">`.

That is ... XML without schema but with CSS support. Cool.

Huh. That led me to wonder whether anyone has created CSS for DocBook, and it appears it exists.

http://www.badgers-in-foil.co.uk/projects/docbook-css/

Yes, I know about them. But I don't think they are very useful outside custom HTML components (JS required). I'd rather use the standard semantic elements as much as possible since they provide good SEO / accessibility out of the box.

This is cool! I was actually wondering about how to make this work recently and obviously did a bad job of researching it because I didn't realise it already existed[0].

One place I'd love to see this is in a classless html framework. My experience is you always wind up wanting something like cards, and then either writing classes, or having a slightly magic "use these elements in this order" incantation[1].

It would be great to have a minimal framework that peppers in a couple elements of the kind <card>, <accordian> etc.

[0] I did ask an LLM at one stage too, and it also didn't mention this behaviour exists.

[1] pico css does this.for.example for cards/accordians

"You can" and "you should" are very much not the same thing on this; of course there'll be exceptions but in the general case I'd say there will be an existing tag you should use.

If you try this with React + TypeScript, expect some paper cuts. You’ll need a .d.ts file for your custom elements so TypeScript’s JSX checker accepts them. Even then, eslint can complain about namespaces.

JSX solves the "named containers" problem in code:

  <ArticleHeader>
    <ArticleQuote>...</ArticleQuote>
  </ArticleHeader>

But the tags don't show up in the real DOM. Everything compiles to plain divs. Whether that matters depends on if you care about inspecting the rendered HTML or just the source code.

I find this fun and whimsical, but surely it’s an accessibility nightmare.

Custom elements have their purpose, but in most cases you don't need them and existing elements suffice.

With how this article was written (the use of "then" when they meant "than", mentioning "article-heading" when that is not in their previous example, but rather "article-header") makes me believe this didn't get much thought on the topic they wrote about, but rather wrote up a quick post.

Additionally, the problems that they bring up can be mitigated with the use of BEM structure for their class names.

I learned this back when HTML5 was brand new around 15-ish years ago. If you wanted to use the new tags like <article>, the only “polyfill” needed was some css styles. You can see it in the early versions of the HTML5 Boilerplate:

https://github.com/h5bp/html5-boilerplate/blob/v0.9/css/styl...

I realized that I could just make up tags and style them and it was work.