I may be misremembering this (I can’t find the source), but I seem to recall @mbutterick writing somewhere years ago (perhaps 2015 or earlier?) that people shouldn’t be afraid to create and use their own HTML elements. So for example, if I was writing some technical documentation that made use of highlighted “warning boxes” I should consider simply making up a <warning> element, off the cuff as it were, and styling it with CSS. I also seem to recall seeing such custom elements in at least one of his projects at one point.
I have fiddled with this in the past and found that it seems to work in practice. But I’ve always wondered whether it was a good idea, whether it was really safe, and what would make it preferable to using, say, a div with a class. If we do in fact have custom elements as our birthright I would love to make them part of my toolkit. But I am hesitant, since it goes against the mentality I was given in the early 2000s of running everything through the W3C validator or whatever (which admittedly I haven’t done in years).
So my questions for Matthew are:
Is this a position you recall taking and writing in favor of (or am I crazy)?
Beyond the fact that it seems to work in practice, what practical reality might I be missing that makes custom elements totally fine and safe?
Somewhere in the HTML spec is a statement that all unknown elements are treated as display: inline. Furthermore, back in the day, I noticed that G____ Analytics was injecting elements with custom tags into the page with no ill effects. Why, then, oh why, can’t I?
(I have long taken a dim view of the W3C; an even dimmer view of the validator. I think makers of web pages should do whatever they want and see what happens because hacking things is fun. Moreover, browsers are full of bugs. Working around them is a cost that has been imposed on web designers by Big Tech since the beginning. Turnabout is fair play, etc.)
In practice there are two complications:
For inline elements, this technique works fine. For block elements it’s knottier, because the browser doesn’t know what things are blocks until the CSS is loaded, which forces certain things to re-layout and re-render. At the time, this could cause strange artifacts. Today, the whole interplay of network download & rendering is much different, so I think this consideration is obsolete.
The bigger annoyance is: how do you write CSS selectors that target all custom blocks? In CSS we already have this annoyance that there’s no way to select all the top-level block-like things — we have to write p, div, li, h1 ··· and so on. Using custom tags for blocks just means you lose the convenience of talking about div elements as a group.
Consequently, I moved away from the custom-tag technique and opted for <div class="whatever">.
PS There is also a long-burbling thing called Web Components that is now well supported but IIUC that’s a heavier abstraction.
A related observation regarding validators: at some point the script was flipped and we started asking the browser to pass tests: Acid, Acid2, Acid3 etc., as well as sites like caniuse.com, and I think this has done more to make my life easier than all the carping to designers about validating their markup.
Using custom tags for blocks just means you lose the convenience of talking about div elements as a group.
Surely this can be alleviated with the use of a CSS preprocessor, though, right?
Brian Kernighan, co-inventor of C, also worked on the typesetting package troff. I recall reading a talk he gave saying that one must be mindful that machine-generated markup can reach levels of complexity that can soon overwhelm layout parsers and display engines that were designed around human-level complexity. (I think this will likely become one of the side effects of generative AI tools—their output will overwhelm current software through sheer bulk & complexity.)
