You Can Make Up HTML Tags
Key topics
The web development community is abuzz about the little-known fact that you can create custom HTML tags, sparking a lively debate about their usefulness and the role they've played in the evolution of modern web development. While some commenters, like lofties, wax poetic about the elegance of custom elements, others, such as troupo, counter that they're verbose and hinder low-level optimizations. A notable consensus emerges around the value of custom elements' interoperability, with WickyNilliams highlighting their ability to seamlessly integrate with various frameworks and libraries. As the discussion unfolds, it becomes clear that custom elements have been quietly empowering developers to create more flexible and maintainable code, even if they haven't always been the darling of the web development zeitgeist.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
21m
Peak period
149
Day 1
Avg / period
32
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 28, 2025 at 9:47 PM EST
12 days ago
Step 01 - 02First comment
Dec 28, 2025 at 10:08 PM EST
21m after posting
Step 02 - 03Peak activity
149 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 8, 2026 at 9:25 PM EST
22h ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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 `-`.
Quoth the standard: "The use of HTMLElement instead of HTMLUnknownElement in the case of valid custom element names is done to ensure that any potential future upgrades only cause a linear transition of the element's prototype chain, from HTMLElement to a subclass, instead of a lateral one, from HTMLUnknownElement to an unrelated subclass."
You can customize it using the Custom Element API: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
I agree the need for everything to be a react app by default has gotten out of control. But I think if you’re a startup with unknown future needs it’s hard to ignore the flexibility and power of something like react. If you know you’re just making a CRUD app and good old fashioned form POSTs will do then it’s beautiful to have that speed and the lightweight pages.
Very confused by statements like these.
They are extremely verbose.
They are too high level, preventing many low-level optimizations.
They are too low-level, preventing you from using/implementing them without going into the details of how they actually work.
They break many platform assumptions and conventions, creating no end of problems both for end users and implementers, and needing dozens of new specifications to fix glaring holes that exist only because web components exist. All of those specs? A heavy dousing of Javascript of course.
Even the people who push them heavily cannot agree on what they are good is and what the goal of them is
This is a unique advantage to WCs. And it's such a compelling advantage that it makes almost all the downsides tolerable. At least if you are in a position where your component might be used in many places. Design Systems are a good example. The consumer can be any app, built on any technology.
And there are plenty of downsides. But they are mostly felt by the author, not the consumer. Similar to how TS libs can be very complex to author because of type level gymnastics, but when done right are easy to consume.
(I do not push them heavily, but I can appreciate strengths and weaknesses of all tools)
I think someone once called them leaf components, and on this I agree.
But I agree they tend to be better suited as "leafier" components
Funnily enough this is exactly what original proposal of web components was against :)
First web components proposal is from 2011. First specs are from 2011-2013.
React was introduced in 2013 and didn't gain much traction until at least a year later.
Vuejs was publicly announced in 2014.
"That proposal" was a talk by Alex Russel in 2011: https://web.archive.org/web/20121119184816/https://fronteers...
Web Components are not a single proposal. Their core originally is three specs:
- Custom Elements
- Shadow DOM
- HTML Templates
Custom Elements v0 was implemented by Google, but the API changed (especially with ES6 classes making their way into all major browsers), and now everyone's on Custom Elements v1. There are very little fundamental changes between the two beyond that.
Shadow DOM is there, is an endless source of bizarre problems that literally no one has, and in the end will need ~30 different specs and changes to the browser to fix those problems (for a sample see https://w3c.github.io/webcomponents-cg/2022.html)
HTML Templates were only implemented in Firefox, and were removed in favor of JavaScript-only HTML Modules which were eventually scrapped in favor of on-off additions to JavaScript imports (see e.g. "CSS Module scripts" https://web.dev/articles/css-module-scripts)
> was proposed based on lessons learned from (or inspired by?) React/Vue.
Lol. The world wishes it were so. There rarely was such an insular group of people developing major web standards as those developing web components. They were hostile to any outside input or influence and listened to no voices, and looked at no implementations but their own.
Have you followed anything in the last 5 years? Outside of bootcamp students, this has been on the decline for a while… in some cases overcorrecting for where a SPA might make more sense.
Web Components are underrated for sure. I had a need for a custom element[0] and it was not difficult to implement.
[0]: https://github.com/zikani03/hypalink
https://github.com/aaviator42/yes-script
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.
It does! You're looking for <https://lit.dev/docs/components/shadow-dom/>
By default, Lit renders into a shadow DOM. This carries benefits like encapsulation (including the style encapsulation you mention). If you prefer global styles, you can render into light DOM instead with that one-line switch.
When you need to re-render your component, how does the component know not to replace the child content you rendered, Vs the child content it rendered into the light DOM. That's why the shadow DOM and slots were necessary, because then there's no intermingling of your content Vs the component's
This may not be a problem if you don't intend to compose your components. But if you do you will hit limits quickly
https://github.com/gitaarik/lit-style
While you can easily turn rendering to shadow DOM off on a per-component basis, that removes the ability to use slots. It only really works for leaf nodes.
Pulling a stylesheet into every component is actually not bad though. Adopted stylesheets allow you to share the same stylesheet instance across all shadow roots, so it's quite fast.
My secondary concern with Lit is the additional complexity of using shadow and light DOM together in long lived React/Angular apps. Adding a new paradigm for 75+ contributors to consider has a high bar for acceptance.
And yes attempting to add a new paradigm for that many people is I am sure quite the task. More political than technical in many ways as well.
Thanks for sharing!
Even if this custom element trick didn't work, I don't see why one would need to count divs (at least if you control the markup, but if not then made-up tags aren't an option anyway). The article even mentions using class names as an option.
So yeah, I guess what wasn't obvious from my statement of gratitude was that I appreciate knowing that there is a more concise way of keeping track - even without CSS styling. If I make up tags, they will just inherit default styling but to my eye I can be clear about where things are closed, and where to insert things later. Make more sense?
Not the best example, because in this case, you could just use real HTML tags instead
Note: be sure to avoid too many `:has(:nth-child(n of complex selector))` in case of frequent DOM updates).
All I say above is a just a particular way of thinking about document markup, of course. If you don't agree with it, then tags are probably the wrong way to express what you're thinking of.
It made sense in 1996. It does not make sense now.
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.
It's a bit more subtle then that. HTML5 defines "Content Models", two of which are 'Phasing Content' and 'Flow Content'. Phasing Content can only contain text and text-like tags (em, strong, bold) whereas Flow Content can contain anything.
Technically <span> is defined as accepting Phrasing Content and <div> accepts Flow Content. Changing this with CSS doesn't change the content model.
Although browsers are very forgiving so it all works anyways.
https://html.spec.whatwg.org/#the-span-element
https://html.spec.whatwg.org/#the-div-element
https://html.spec.whatwg.org/#content-models
:where(:not(:defined)) { display: block }
Inline styling is kind of the default in HTML.
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.
Custom elements solve exactly this problem. You can now do:
And then set up the listener: And the browser will ensure that it always sets up the listeners for all of the expanders, no matter whether they are loaded on the page initially or dynamically injected later. Without this you would have had to jump through a bunch of hoops to ensure it. This solves the problem elegantly.Above code will only work when the Web Component is defined after DOM has parsed; using "defer" or "import" makes your JS file execute after DOM is parsed, you "fixed" the problem without understanding what happened.
I blogged about this long time ago: https://dev.to/dannyengelman/web-component-developers-do-not...
► execute <script> at bottom of file
► execute <script defer>
Both do the same; they execute script after DOM was parsed. When your JS creates GUI you now have to battle FOUCs.
► "import" loads your script async
so it _could_ load before _all_ DOM has parsed... but 9999 out of 10000 scenarios it won't
Simply render your <element> (server-side is fine) and whenever the JavaScript downloads and executes your custom elements will mount and do their thing.
I'm really just pushing back on the idea of using them for CSS formatting purposes of general text and layout instead of classes.
If you see an unfamiliar tag that has a reasonably simple name, you simply don't know if it's native or for formatting.
That's confusing. It's taking two categories of things and mixing them so you can't tell them apart.
So now you've got to try to enforce some practice of using hyphens in all tag names that used to be class names, even if they're a single word that has no place for a hyphen?
It's getting even more confusing now, you see? Not less.
You just use it (single word) and style it (CSS) and it works. You don't have to "create" anything.
But yeah I also do see the confusion part, if a person new to HTML sees these custom tags being used it might think it can create one too and not realize it must contain a dash, and it would still work. So yeah in that sense, indeed it's confusing if you're unfamiliar with it.
But having multiple </div></div></div> at the end of a large block of HTML is also confusing, often resulting in closing too many / too few divs. Having </nav-item></nav-bar></main-header> is much better. So yeah it has it's pros and cons I guess.
Doing this for syntax highlighting on https://janetdocs.org/ shrank the homepage's .html from from 51kb to 24kb, or 8kb to 6kb compressed (at the time).
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.
Yeah, the sites would be ugly and kind of obnoxious, but there was, for want of a better word, a "purity" to it. It was decidedly uncynical; websites weren't being written to satisfy a corporation like they all are now. You had low-res tiling backgrounds, a shitty midi of the X-files theme playing on a bunch of sites, icons bragging about how the website was written in Notepad, and lots and lots of animated GIFs.
I feel like the removal of blink is just a symptom of the web becoming more boring. Instead of everyone making their own website and personalizing it, now there's like ten websites, and they all look like they were designed by a corporation.
Before blogging was called "blogging," people just wrote what they wrote about whatever they wanted to, however they did that (vi? pico? notepad? netscape communicator's HTML editor? MS frontpage? sure!), uploaded it to their ISP under ~/public_html/index.html or similar [or hosted it on their own computer behind a dialup modem], and that was that.
Visibility was gained with web rings (the more specialized, the better -- usually), occasional keyword hits from the primitive search engines that were available, and (with only a little bit of luck necessary) inclusion on Yahoo's manually-curated index.
And that was good enough. There was no ad revenue to chase, nor any expectation that it'd ever be wildly popular. No custom domains, no Wordpress hosts, no money to spend and none expected in return. No CSS, no frames, no client-side busywork like JS or even imagemaps.
Just paragraphical text, a blinking header, links, and the occasional image or table. Simple markup, rendered simply.
Finish it up a grainy low-res static gif of a cat (that your friend with a scanner helped make from a 4x6 photograph), some more links to other folks' own simple pages, a little bright green hit counter at the bottom that was included from some far-flung corner of the Internet, a Netscape Now button, and let it ride.
It was definitely a purer time.
I modified `.blink` to `blink` so it will target the tag instead of the class and it seemed to work
I've never been much of a frontend person, so gluing stuff together with JQuery was kind of my go-to until I was able to abandon the web.
Most browsers never implemented it in the first place. Safari, Chrome, IE and Edge never had it. In terms of current browser names, it was only Firefox and Opera that ever had it, until 2013.
Regardless, I stand by my comment. Monsters! I want my browser to be obnoxious.
In theory, in 1996 Netscape and Microsoft agreed to kill <blink> and <marquee> <https://www.w3.org/People/Raggett/book4/ch02.html>, but although they were kept out of the spec, neither removed its implementation, and then IE dominated the browser market, and <marquee> became popular enough that the remaining parties were bullied into shipping it (Netscape in 2002, Presto in 2003, no idea about the KHTML/WebKit timeline), and so ultimately it was put into the HTML Standard.
Oh those times. IE accepted <table><tr><td><tr></table> whereas Nestscape demanded <tr><td></td></tr></table> and would just render anything else blank
Nothing to replace it with to afaik.
It was so satisfying being able to animate something, and immediately have the ability to create code out if it.
I have not found a platform to replace that, though GameMaker gives something of a facsimile.
Yes I know about Ruffle, but I don’t really want to make a retro game that targets an emulator, I want something that’s consistently updated.
Also Animates pricing model is bullshit.
Plenty to replace it with to afaik.
https://ruffle.rs/
Sites like Kongregate amd albinoblacksheep are using it to revive their old catalog.
On the one hand I kind of want to use any random tag and have it work.
On the other hand ...
I am not 100% sure, but I think I kind of prefer the div tag.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.
The HTML5 specification was released in 2014, so tags like article, section, header, figure, etc. have been around for more than a decade; they are not that new.
Serious question: are you saying that an entire webpage using only div and p tags is easier for you to grok than if the same webpage used standard tags like article and blockquote?
You're leaving so much functionality on the table. It also sounds like you're not using ARIA either, so your site is inaccessible to users of assistive technology.
You could use roles on your div tags to give a screen reader a fighting chance:
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.
If you're interested in my approach to custom elements I created: https://github.com/crisdosaygo/good.html
It utlizes custom elements, has autohooks for granular DOM updates, uses native JS template literal syntax for interpolation, imposes ordered component structure:
It even has a bit of a "comment node" hack to let you write "self-closing custom elements" Good.HTML is the ride-or-die framework for BrowserBox.Unfortunately, I don’t have anything public to show at the moment. Maybe I’ll blog about the approach some day.
In CSS, how do you target <div slot="hero-blurb"> based on the "hero-blurb" slot?
``` <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/clock</built-in> <keyword>:cputime</keyword> <keyword>:tuple</keyword>)) ```
The article states that anything with a dash is guaranteed not to be and another commenter here shared their strategy that involved a naming convention like <x-special>, <x-symb>, etc. Perhaps substituting x for j would make sense and alleviate the concern of possible future clashes with web standards
[0]: https://idiallo.com/blog/revisiting-my-old-javascript
https://waspdev.com/articles/2025-06-29/css-features-web-dev...
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
But they'll never add new standard tags with hyphens.
They dropped numbered versions. Now it is just HTML which is continuously evolved in a backwards-compatible manner.
> And if there will be an html6 why can't we just state "use version 5 in this document"
Because browser vendors are opposed to explicit versioning, since it introduces multiple rendering modes.
<tagname> = always an HTMLUnknownElement until the WHATWG adds it as new Element.
<tag-name> = UNDEFINED Custom Element, valid HTMLElement, great for layout and styling
Upgraded with the Custom Elements API it becomes a DEFINED Custom Element
---
► This is standard behaviour in all browsers that support the Custom Elements API. Since 2020 in all browsers when Microsoft Edge switched to the Chromium Engine. And already in Chrome, Safari, Firefox many moons before 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 :pseudo selector targets standard HTML tags and JavaScript defined Custom Elements
► Thus the CSS :(:)pseudo selector targets the 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
It's certainly better than calling everything a div.
> breaks accessibility features
I don't know if I'd call it breakage to just... not use them where they should be used. Of course if a real tag exists that adequately matches the author's intent, that should be preferred over a made-up one.
It's not. For semantic purposes <my-element> is the same as <div class=my-element>. So on the surface they are equivalent.
But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available so <my-aside> rather than <aside class=my-aside> so in practice it is probably worse even if theoretically identical.
Basically divs with classes provide no semantic information but create a good pattern for using semantic elements when they fit. Using custom elements provides no semantic information and makes using semantic elements look different and unusual.
You could say the same about divs. I’ve seen pages where everything is a div. No paragraphs, no headings, no tables, no lists, just divs.
This article is written for web developers. I’m not sure who you think you are addressing with this comment.
But semantic purposes are not all possible purposes.
I can only speak for Chromium, but this isn't about the UA stylesheet; everything in the UA stylesheet applies to custom elements just the same as the more standard HTML elements (e.g. the rule for [popover] will apply just fine to custom elements AFAIK), and there is no [hidden] rule in the UA stylesheet. You're probably mixing it up with the fact that hidden is a HTML presentation attribute, similar to how you can write <div align="right"> and it will become its own little property value set that gets applied to the element. That is indeed only the case for HTMLElements. (The difference matters for priority in the cascade; in particular, presentation attribute style has zero specificity.)
With classes, I can do:
With custom tags, that is not possible because variable names cannot have - signs in them.HTML5 Shiv was needed, with added history https://www.paulirish.com/2011/the-history-of-the-html5-shiv... (2011)
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
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
Indentation can help.
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.
If I were going to use them, I'd be inclined to vendor them just to prevent any sort of collision proactively
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.
27 more comments available on Hacker News