<tag-name> are NOT unrecognized tags!

I blogged about this: https://dashed-html.github.io

◄ <tagname> = always an HTMLUnknownElement until the WHATWG adds it as new Element.

◄ <tag-name> = (No JS!) UNDEFINED Custom Element, valid HTMLElement, great for layout and styling

◄ Upgraded with the JavaScript Custom Elements API it becomes a DEFINED Custom Element

---

► This is standard behaviour in all browsers. Chrome (2016) Safari (2017) FireFox (2018) Edge (2020)

► The W3C HTML Validator accepts all <tag-name> Custom Elements with a dash as HTMLElement. It does not accept <tagname> (no dash), those are HTMLUnknownElement

► The UA - UserAgent StyleSheet (Browsers default stylesheet) defines CSS [hidden] { display:none }. But Custom Elements do not inherit the default stylesheet; so you have to add that behaviour yourself in your stylesheet.

► <DIV> is display:block only in the UA StyleSheet You have to set the display property on these Custom Elements yourself (You will forget this 20 times, then you never make the mistake again)

► The CSS :defined pseudo selector targets standard HTML tags and JavaScript defined Custom Elements

► Thus the CSS :not(:defined) pseudo selector targets the UNDEFINED Custom Elements; they are still valid HTMLElement, CSS applies like any element

► DSD - Declarative ShadowDOM: <template shadowrootmode="open"> creates the same undefined Custom Elements with a shadowDOM

  <div class=article>
  <div class=article-header>
  <div class=article-quote>
  <div class=quote-body>
  ... a bunch more HTML ...
  </div>
  </div>
  </div>
  </div>

  <article>
  <header>
  <blockquote>
  <p class=quote-body>
  ... a bunch more HTML ...
  </p>
  </blockquote>
  </header>
  </article>

I've been doing this for about three or four years. Clever idea, tricky in practice. I don't think I'd recommend this approach broadly. But it works for me.

It's definitely possible to take it too far. When most tags in your HTML are custom elements, it creates new readability problems. You can't immediately guess what's inline, what's block, etc. And it's just a lot of overhead for new people to learn.

I've arrived at a more balanced approach. It goes something like this:

If there's a native tag, like <header> or <article>, always use that first.

If it's a component-like thing, like an <x-card> or <x-hero>, then go ahead and use the custom tag. Even if it's CSS only, without JS.

If the component-like thing has sub-components, declare the pieces using slot attributes. There will be a great temptation to use additional custom tags for this, like <x-hero-blurb> inside <x-hero>. In my experience, a <div slot="hero-blurb"> is a lot more readable. The nice thing about this pattern is that you can put slot attributes on any tag, custom or otherwise. And yes, I abuse the slot attribute even when I'm only using CSS, without JS.

Why bother with all of this? I like to limit my classes to alteration, customization. When I see a <div slot="card-content" class="extra-padding-for-xyz">, it's easy to see where it belongs and what makes it unique.

Some of you will likely barf. I accept it. But this has worked well for me.

11 year old example (but still funny): https://github.com/ebidel/html5demos/blob/master/html5-demos...

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">`.

By default, they will behave like spans.

You can customize it using the Custom Element API: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

Many years ago, I decided to reinvent the `blink` tag, because the monsters who make browsers removed support for it.

I didn't know you could just make up tags, but I figured I'd give it a shot, and with a bit of jquery glue and playing with visibility settings, I was able to fix browsers and bring back the glorious blinking. I was surprised you could just do that; I would have assumed that the types of tags are final.

I thought about open sourcing it, but it was seriously like ten lines of code and I suspect that there are dozens of things that did the same thing I did.

I used this to implement <yes-script>, the opposite of <noscript>, to be able to designate sections of a page to be hidden if JS was disabled. You can of course do the same thing with classes, but custom tags are fun.

https://github.com/aaviator42/yes-script

I also saw this at https://lyra.horse/blog/2025/08/you-dont-need-js/#fn:3 :

> You are allowed to just make up elements as long as their names contain a hyphen. Apart from the 8 existing tags listed at the link, no HTML tags contain a hyphen and none ever will. The spec even has <math-α> and <emotion-> as examples of allowed names. You are allowed to make up attributes on an autonomous custom element, but for other elements (built-in or extended) you should only make up data-* attributes. I make heavy use of this on my blog to make writing HTML and CSS nicer and avoid meaningless div-soup. ↩

(HN filtered out a "face with heart eyes" emoji from the second example.)

> <main-article>

> <article-header>

> <article-quote>

> <quote-body>

Not the best example, because in this case, you could just use real HTML tags instead

  <article>
  <header>
  <blockquote>
  <p>

You sure can! They all have inline defaults like `<span>` so set some CSS baseline on them as needed, but this is like the best kept secret of HTML or something? Unknown tags will become `HTMLUnknownElement` and behave like a span.

Edit: the reason for avoiding this in the past was name-spacing. But the standard says you can use a hyphen and then you're OK, native elements won't ever use a `-`.

Edit 2: also it's great because it works fine with CSS selectors too. Write stuff like `<image-container>` in plain HTML docs and it's fine.

Edit 3: but also `<albums>` tags and etc which won't be adopted into the HTML standard soon work too if they don't conflict with element names, and the rare case that they might be adopted in the future as an element name can be resolved with a simple text search/replace.

Edit 4: This all really has little to do with javascript, but you can use `querySelector` and `querySelectorAll` with any of these made up names the same as any native name too.

It's very nice to write. I used and liked vue for a little while when it was needed(?) but modern HTML fills that gap.

In the olden days, internet explorer couldn't support html5 tags. I found a snippet of code from my 2010 library [0] that I used to use to remedy the problem. You see if you created the tags via JavaScript, IE would somehow recognize them. You could discard them right after. Here was my script:

    (function(d) {
        'abbr article aside audio bdi canvas data datalist details figcaption figure footer header hgroup mark meter nav output progress section summary time video'.replace(/\b\w+/g,function (a){
            d.createElement(a);});
    })(document);

[0]: https://idiallo.com/blog/revisiting-my-old-javascript

This is how you can set default styles for all your custom elements:

    :where(:not(:defined)) {
         display: block;
    }

This is the basis of web components and of all popular frameworks. In this model, the only use for a plain <div> is content that doesn't need special reusable layout or behavior. Everything cool gets promoted to a custom component.

What makes this awesome is that no future version of HTML can make your custom component stop working; it's supported down at the "bare metal" level.

I wrote an article [0] a couple years ago about how and why this came to be.

0: https://levelup.gitconnected.com/getting-started-with-web-co...

But there's no real reason to, and it just adds confusion around which elements are semantic -- bringing formatting, functionality, meaning to screen readers and search engines, etc. -- vs which are custom and therefore carry no semantic meaning.

If there's no native semantic tag that fits my purposes, I'd much rather stick to a div or span as appropriate, and identify it with one (or more) classes. That's what classes are for, and always have been for.

Support for custom HTML elements seems more appropriate for things like polyfills for actual official elements, or possibly more complicated things like UX widgets that really make sense conceptually as an interactive object, not just CSS formatting.

Using custom element names as a general practice to replace CSS classes for regular formatting just feels like it creates confusion rather than creating clarity.

https://lit.dev/

That's the premise behind Lit (using the custom elements api)! I've been using it to build out a project recently and it's quite good, simpler to reason about than the current state of React imo.

It started at google and now is part of OpenJS.

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.

I was there like fifteen - twenty years ago before the hyphen standard and shadow dom and all that when JS libraries briefly leaned into just making up their own elements. I think everyone collectively agreed that it was a bad idea and it fell out of popularity.

If I were going to use them, I'd be inclined to vendor them just to prevent any sort of collision proactively

    <donatj-fancy-element>
        <donatj-input />
    </donatj-fancy-element>

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

Worth noting you can't define special parsing rules using custom elements, such as for inferring omitted tags like is done for predefined elements all the time. The behavior of parsing HTML fragments with customized standard elements using the browser API is basically underspecified since it lacks a context element which however is needed for inferring required omitted elements such as <head> and <body>, or <html> itself. What about custom elements appearing as child content of other custom elements?

For merely defining custom elements you need JS anyway, so these aren't a technique intended for text authors. Yet as another way to organize code in webapps, custom elements are competing with JS which already has multiple module and namespace and OO import features that are much more flexible.

So as usual, random people on github (aka WHAT working group individuals aka Google shills) reinventing SGML, poorly. Because why not? The end goal always has been to make ad blocking an infeasible arms race and gather "telemetry."

This is what Angular does, where an Angular component is typically rendered as a custom tag. I find it to be one of the (very) few nice things about Angular, as it can be helpful to track down components in a large codebase. I haven’t used React for many years, but makes me wonder if custom tags as a convention would be similarly useful.

The things should be as easy as possible.

The goal is to make content readable by anything. As more users access information through systems like ChatGPT instead of visiting websites directly, content that isn’t easily interpreted by AI crawlers risks becoming effectively invisible.

see: https://github.com/ai-first-guides

That's how https://janetdocs.org/ does syntax highlighting:

``` <pre><code class="janet">(<special>defn</special> <symb>bench</symb> <str>`Feed bench a wrapped func and int, receive int for time in ns`</str> [<symb>thunk</symb> <symb>times</symb>] (<special>def</special> <symb>start</symb> (<built-in>os&#x2F;clock</built-in> <keyword>:cputime</keyword> <keyword>:tuple</keyword>)) ```

I'd like to share Shoelace [0], a library of nice web components I used long ago for some websites. It's now part of Web Awesome (a company behind Font Awesome), though it seems like the original author, Cory, is still working on it.

[0] https://shoelace.style/

Can check out the DOM of https://radio4000.com to see how custom-elements and web-components can be used to describe the entire app (and allow custom themes, and more) (source: https://github.com/radio4000/components) — no css class, full description of the app's state via html attributes (reflected in styles)

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.

There is a CSS library that utilizes this behavior: https://github.com/doeixd/CSS-Tags

You can, but maybe you shouldn't.

If, for some reason the CSS doesn't load, your site may break completely instead of degrading gracefully. Maybe it will mess with people who have an unusual browser configuration too. It may look nice on your side, but on the user side, I only see disadvantages. It may look like it saves a few bytes, but with compression, it may not.

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

> If you include hyphens in the name, you can guarantee that your tag won’t appear in any future versions of HTML.

Which future version? Is there something I'm missing? I'd like to have html6 that has feature parity with native, but I'm afraid we got html5 and just stopped there. And if there will be an html6 why can't we just state "use version 5 in this document" so there won't be any name clashing between supported and custom tags?

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.

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

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/

My problem with custom tags is that they require a hyphen, and that makes it impossible to have consistency between tag names and variable names.

With classes, I can do:

    carList = document.querySelector('.carList')

I probably wouldn't do this for a lot of reasons.

That being said, if you read through that post and were intrigued, you might also like custom web components: https://web.dev/articles/custom-elements-v1

It's a simple way to add more to your "made up" HTML tags. So you could have a tag called <my-code>, for example, that automatically has a copy button and syntax highlights the code.

Wow, this is great, unlocks lots of freedom. I was under the impression that this was not possible, maybe through web components or <slot>.

As a side note, I’ve been going through all the HTML elements slowly to learn the fundamentals, and it turns out that lots of elements are just a <div> or <span>, with different default styles and default ARIA things.

And a <div> is just a <span> with display block…

This and TFA both help me to realize HTML is pretty darn simple.

As someone who writes html only rarely (I'm more of a "backend" guy, and even use that term loosely.. most of my webdev experience dates back to the CGI days and often the html was spat out by Perl scripts) and usually in vim, I am pleased to know there is an in-built solution outside of me properly indenting or manually counting divs. Thanks for enlightening me.

Exactly why I banned React from my pipelines years ago, native Web Components + dispatchEvent gives you the modern web without bloat and churn, and Vite for a lightweight HMR thanks to native ES Modules.

Server-side you can use jsdom to polyfill document, it supports Web Components too.

Many years ago, IE requires `document.createElement`.

HTML5 Shiv was needed, with added history https://www.paulirish.com/2011/the-history-of-the-html5-shiv... (2011)

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

You've always been able to do it, doesn't even need to be HTML, serialise as XHTML and you can include the tags on your own namespace and have separate CSS for them.

<!DOCTYPE html>

<html

        xmlns="http://www.w3.org/1999/xhtml"

        xmlns:ns1="mynamespace"

        xmlns:ns2="yournamespace"

<body>

<CustomElement>Hello</CustomElement><!-- Custom element in the XHTML namespace -->

<ns1:CustomElement>Hello</ns1:CustomElement>

<ns2:CustomElement>Hello</ns2:CustomElement>

<style type="text/css">

    @namespace ns1 "mynamespace";

    @namespace ns2 "yournamespace";

    CustomElement {

        color:green;

    }

    ns1|CustomElement {

        color:red;

    }

    ns2|CustomElement {

        color:blue;

    }

</body>

</html>

https://blog.jim-nielsen.com/2023/html-web-components/ - Jim Nielsen has a series of posts on how to use made up HTML tags in a way that doesn't just fail to nothing when the javascript defining the custom-element doesn't get successfully executed.

Isn't this the basis for every web framework? E.g., Vue Templates?

If this works, then the point of having standards, is just for screen readers??

I will refuse this idea until it is widely known, accepted, and used by everyone. Div with class is easier to inspect and modify with pseudo. I wonder what would happen with JS getting the element with this, too.

the comments here informing us they default to behaving like <span> instead of like <div> is the biggest disappointment of my day so far

You can but you never ever should. Do not do this. Use the `class` attribute to provide extra context about the kind of data your tag represents, that is what it is for.

> Good luck trying to insert something inside of “article-heading” but after “article-quote” on the first try.

You don't need much, but an editor - collapse the sections to get the view as small as in the blog snippet, and then you'll have both opening and closing of the tag you're in highlighted, so you won't miss and won't need any luck

> Good luck trying to insert something inside of “article-heading” but after “article-quote” on the first try.

Indentation can help.

I was forced to use this years ago because there is only a :nth-of-type selector, but no :nth-of-class. So whenever you need nth-of-class, switch to made-up tags and use nth-of-type. (A tag is a type.)

i'm very curious how screen readers would handle this. what a terrible idea

Hmmmm.

On the one hand I kind of want to use any random tag and have it work.

On the other hand ...

    <div class=main-article> # or <div class="main-article">

    versus

    <main-article>

I understand that it is not the same semantically, but I am using div tags and p tags a LOT. I avoid the new HTML tags for more semantic meaning as this adds cognitive load to my brain. I'd rather confine myself to div and p tags though - it is just easier. And I use proper ids to infer additional information; it is not the same, but I kind of want to keep my HTML simple too. So I don't want to add 500 new custom HTML tags really. Even though I think having this as a FEATURE, can be useful.