◄ <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
> The UA - UserAgent StyleSheet (Browsers default stylesheet) defines CSS [hidden] { display:none }
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.)
I'm a bit miffed about the dash. I wish it was a colon. Then well established XML could be simply name-spaced in, and then either styled with css and enhanced with JS. I suspect it wouldn't be that difficult to write something for nginx or apahce that simply converted the colon to a hyphen. Oh well, it cannot be 1999 forever.
Mainly because it isn't semantic and breaks accessibility features. If you find yourself writing layouts like this you're probably ignoring a bunch of useful stuff like <aside> <article> <menu> etc. Unless you manually configure it yourself, screen readers won't know what's important to read, tabindex won't know where to jump around, and form fields won't know what values to offer.
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 certainly better than calling everything a div.
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.
> 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
This article is written for web developers. I’m not sure who you think you are addressing with this comment.
In any case - the argument is a weak one. To the extent people make the mistake you allege they can make it with classed div and span tags as well and I’ve seen this in practice.
That is a strawman. I never said everyone who uses classes perfectly uses semantic elements.
My point is that if you are using <div class=my-element> you don't have to change your .my-element CSS selector or JS selection code to improve your code to <p class=my-element>. If you are using <my-element> it is much more work to change your selectors and now you have two ways of doing things depending on if you are using a native semantic element or a div (either a tag selector or class selector). You have made your styling code depend on your element choice which makes it harder to change.
<div class=article>
<div class=article-header>
<div class=article-quote>
<div class=quote-body>
... a bunch more HTML ...
</div>
</div>
</div>
</div>
Just one quibble over this specific example (not the broader concept, which is sound): it probably didn’t have to be div soup to begin with. Something like this may have been more reasonable:
<article>
<header>
<blockquote>
<p class=quote-body>
... a bunch more HTML ...
</p>
</blockquote>
</header>
</article>
This example also shows a weakness of custom tags compared with using the class attribute. An element can have only single name but may have several classes. And as classes are unordered set, one cannot in general emulate that with several elements as the nesting introduces an order absent in the class list.
I’d argue it’s a strength. You still have classes and custom attributes to reach for when you want an (effectively) unordered set, the difference is just that you define some boundary that’s exclusive. This reflects reality. Some helper classes work together by just slapping them together, but component-like classes, like a toggle and a hero image, don’t. If you do want to combine them, you need to think about how, potentially rearchitect, and implement it whether you’re using classes or tag names.
Good use case for @container, @scope and :has(), where you forgo class definitions and use --custom-properties on the parent scope/container which are inherited downwards based on the existence of a scoped DOM pattern/container query, or 'upwards' by using a :has(child-selector) on the parent.
Although be sure to avoid too many :has(:nth-child(n of complex selector)) in case of frequent DOM updates.
Honestly it depends what you're doing. A tag name is only correct when it unambiguously specifies the content. As in, a header is just a header - there's no "dual nature" that we have to support by allowing multiple tag names. This means the ontology you're representing has to be "linear" - you can have more specific and less specific tags, but never a "fork" where you could really choose either more-specific tag in order to emphasise a different "part" of the tag. Classes should always be for secondary properties, which are not the main "essence" of the content.
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.
Hot take: div soup isnt bad because html isn't purely structural. It's a natural consequence of a poor design decision. Div soup is a consequence of the design decision to couple html elements to styling, state management, etc.
It made sense in 1996. It does not make sense now.
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.
I'm highly interested in approaches that utilize web grain in a balanced practical way. Do you have a framework/toolbelt or example sites to share? Would love to see.
It utlizes custom elements, has autohooks for granular DOM updates, uses native JS template literal syntax for interpolation, imposes ordered component structure:
I used custom elements extensively in 2014 when support was not as widespread. I think it's a beautiful, elegant solution and I'm still a little bit bitter that React became as big as it was. Now everything "has" to be a SPA because developers want to use React, whereas most users would actually be better served with good 'ol HTML with some custom elements where needed.
> Now everything "has" to be a SPA because developers want to use React
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.
I’ve been getting into SSR with JSX as a template engine using kita. You still get full typescript analysis and composability. It beats any other SSR web templating system I’ve used.
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.
You do the crud app and then they want: just make this to edit inline. You do some Ajax api Call with a tiny js. Then you need more and more. Then you have a mess and you’d be better with react. I still can’t find a project id be better of without react. When I tried without it bite me very quickly.
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
What makes custom elements good is inrerop. I can use them in react, Vue, angular, svelte, solid, or just plain ol' server rendered html. I can switch out the internals entirely for a WC lib, or not, with nobody knowing or caring.
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)
They don't need to be leaf components to still have this strength. I've worked with design systems which have a <my-layout> component near the root which defines sidebar, header etc slots. This still works nicely with react, Vue etc
But I agree they tend to be better suited as "leafier" components
Honestly I couldn't care less what the original proposal said! Things evolve. Utility is found in unforeseen places. That's the nature of ~everything. Personally I'm not a fan of that kind of component but not aligning with some original, preordained vision is a minor nit
Not even sure what argument you're making here. A web component bundles one or more of: markup, styles, functionality. You can't do that with just html such that it's easily consumable in all the ways I mentioned.
As far as I can tell, the whole web components umbrella came into being because React/Vue got really popular, and the spec/browser people said hey let's bring the core common denominator of those into native HTML/JS, as if it would bring us closer to having native Vue/React. Which of course never happened, partly because HTML is fundamentally incapable of having anything but string attribute values, and partly because reactive DOM is basically a hard problem that can't or maybe shouldn't be solved natively.
> As far as I can tell, the whole web components umbrella came into being because React/Vue got really popular, and the spec/browser people said hey let's bring the core common denominator
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.
Right, and that proposal was withdrawn, and a new one, the one we have now, was proposed based on lessons learned from (or inspired by?) React/Vue. Maybe there was a common ancestor or general consensus about the techniques floating around in the community before proposal #1, but it was clearly inferior and flawed, and #2 was the one I'm talking about.
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.
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.
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.
> because the monsters who make browsers removed support for it
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.
Huh, I would have sworn that Internet Explorer had the blink tag at one point, but I think my parents had Netscape and then Mozilla pretty early so maybe that's what I'm confusing it with.
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.
I think I remember reading articles about how to implement blink in IE using behaviors, some IE only thing that didn't take hold(?), Maybe this was around IE5.
Oh those times. IE accepted <table><tr><td><tr></table> whereas Nestscape demanded <table><tr><td></td></tr></table> and would just not render anything else - just blank grey
Humans loved it, when they had to type all this by hand, because missing /td would not kill your page.
Permissiveness won out.
I also remember the day JavaScript hit the net.
and all those "chat rooms" that did <meta refresh> to look live suddenly had no defence against this
Oh those times. <script>document.createElement("table").appendChild(document.createElement("table"))</script> would crash IE, and some similar stupidities could even cause a BSOD as late as Windows 98.
(I think that was one such incantation, but if it wasn’t quite that it was close.)
Good riddance. I once had the honor of being featured together with many other artist on an HP website. It was implemented in Flash though, meaning it existed as a smallish rectangle in the middle of a website; within that rectangle you could click through to browse the exhibition one artwork at a time. This entailed that your path through the Flash app was not connected to the browser's address bar and exhibits did not get a URL of their own. When you wanted to direct others to your piece the only way was by giving them a "Japanese visitor's address", as in "go to this well-known named point (the domain name), from there walk west and when you see a tall black building, turn right and take the third alley to your left, I'm living in the fifth house down that alley".
Although Flash really sucked as a technology, it did inspire a lot of visual artistry on the web. Half of the cool stuff you saw on StumbleUpon was made with Flash by people who weren't proficient with JS/CSS, which weren’t capable enough to achieve the same results anyway.
Flash was fun but it was never built for being responsive and handling desktop and mobile in one app. Everything was basically fixed layout. Adding in that responsiveness would have probably killed the "easy" part.
I just kind of feel like removing it makes the internet less fun. 90's internet was basically a playground for geeky people to make things purely for fun, with basically no ambitions of making any money; people would host their own terrible web pages. My first real introduction to "programming" (other than making a turtle walk around) was when I was nine years old and bought "Make Your Own Web Page : A Guide for Kids" from my school, and this was something a nine year old kid could do because the web was easy and fun to program for. There weren't a billion JavaScript frameworks, CSS was new (if it was even supported), everything was done with tags and I loved it.
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 to satisfy shareholders.
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, blue links that turned purple once clicked, 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.
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.
Nitpick: If a nonstandard element name contains a hyphen (and is otherwise a syntactically valid custom element name), the element's DOM object is an instance of HTMLElement, not HTMLUnknownElement.
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."
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);
It didn't take long before I realized I could just add any random tag, add it to my shim, and render it on any browser.
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.
So, the article doesn't discuss this, but there's actually a really good reason to make up and use custom elements: the browser can hydrate their dynamic behaviour automatically. For example, suppose you have:
<div class=expander>
<button aria-expanded=false>Expand</button>
<!-- Some other stuff here -->
</div>
And you have some JS that handles the expander's behaviour:
for (const expander of document.querySelectorAll('.expander')) {
const btn = expander.querySelector('button');
btn.addEventListener('click', () => {
btn.ariaExpanded = 'true';
});
}
This will work fine for `.expander` divs that are already in the page when the event handler is set up. But suppose you dynamically load new expander divs, what then? Your event handler is not going to retroactively set up their click listeners too.
Custom elements solve exactly this problem. You can now do:
<expander-elem>
<button aria-expanded=false>Expand</button>
<!-- Some other stuff here -->
</expander-elem>
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.
this.querySelector will return nothing when you define this Web Component before (light)DOM is parsed, because the connectedCallback fires on the opening tag.
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.
Beware that connectedCallback runs _every time_ a custom element is added to the dom. So you should make sure to only add event listeners once by tracking internally if the element was already initialized.
Thanks, that's good to know. In some contexts I don't think a custom element is ever added to the DOM more than once, eg in htmx I am responding with HTML markup which is then injected into the page and then just kept there, possibly 'forever' or at least until it is replaced by some new markup from a new response.
Yes, the hydration behavior of custom elements is nice. You don’t even need to do anything special with JS bundle loading.
Simply render your <element> (server-side is fine) and whenever the JavaScript downloads and executes your custom elements will mount and do their thing.
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).
That rule doesn't work in reverse. If there's no dash it could be either.
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.
Aha fair enough, but yeah browsers often allow invalid HTML to just work. But that doesn't mean that the valid usage is somehow flawed. I can understand that the dash can be a bit of a weird rule if you're new to HTML. But I think it's an elegant way to allow users to create custom tags and have readable compact semantic HTML.
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.
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.
I just evaluated Lit for work and while we didn't go with it, it was very nice. I love the base custom elements API regardless of using Lit or not, turns out that's all you really need to make intricate UIs that feel seamless.
Something about Lit/web components that's not written clearly on the label is the hoops you have to jump through to style elements. If you're using tailwind in the whole app, you just want to pull it into your custom elements without much boilerplate. My main app compiles a single minified app.css, it felt not so modular to now include that in every single component. The alternative is create a subclass that injects tailwind into Lit components. It'd be perfect it just had a switch to inherit everything the page already has.
By default, Lit renders into 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.
However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:
static styles = [themeStyles, componentStyles]
Then you define your shared styles in `themeStyles`, which is shared across all components you wish to have the same theme.
oh nice! I didn't know that you can just make it use light dom.
protected createRenderRoot() {
return this;
}
And that's what it takes! I like using tailwind/utility classes so for the styles I'd need to have layers of compiled css files rather than one giant one.
The major downside of using light DOM is that elements cannot compose neatly since there's no delineating between what the component itself rendered and child content.
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
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.
Interesting, I'd be curious to know why you all decided not to go with it if you're open to sharing! Minimally to know if I should look at any other promising frameworks.
I see a good case for my company to use Lit for creating complex components such as highly interactive panels/widgets to be shared between React/Angular apps in our large ecosystem. However the decision was: 1. Prefer sharing plain JS/TS over framework code so try that first and 2. if the component is so complex and tricky to get right, it probably needs to be re-implemented in each framework anyways (or some sort of wrapper)
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.
Ah yeah, definitely a much different equation when introducing this across many apps as a shared component library. Mixing different DOM abstractions together could get tricky for sure.
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.
> 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.)
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
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.
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.
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.
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.
```
<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>))
```
That's kinda cool but the article addresses a major concern with this strategy that is not addressed here. Which is that many of these tags (e.g. <special>, <keyword>, etc) might someday become part of the HTML standard.
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
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.
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">`.
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
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:
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.
"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.
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.
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)
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:
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.
> 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?
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.
> And a <div> is just a <span> with display block…
It's a bit more subtle than 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 and this is very in the deep end, I can't think of the last time I've consciously thought of this stuff.
It's one of my favorite little tricks. I use it when I'm building applications that have a lot of nested "contexts" and its not just styling/layout. Makes it easier to search for and jump to these contexts and mentally parse them. But I use it sparingly. It gets out of hand fast if you start doing <parent-nested-2ndchild-list-item>.
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.
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.
A more common alternative to counting divs would be CSS classnames or (for unique elements on the page) IDs. You'd do `document.querySelector('.my-class')` to locate `<div class="my-class">` or similar, rather than using the fact that e.g. something is nested 3 divs inside <body>.
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.
Sorry, I didn't mention class names because the article explicitly did and I assumed that my aversion to the extra typing would be presumed by a reader of my comment. My mistake.
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. I was talking about the manual editing (in vim, as I mentioned), rather than any dynamic query selectors. Make more sense?
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.
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."
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.
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.)
IMHO this also makes custom tags no longer very useful beyond custom HTML components (JS is also required for that). The standard tags provide good semantics, SEO and accessibility out of the box.
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.
Frameworks generally change those to standart tags at build time. Vue can be used without a build step so it indeed uses custom tags for components in that scenario but it is not very common to use Vue without a build step.
I think it makes sense that if HTML detects an unknown element that it doesn't give it block styling automatically. Only if you specifically specified it for that type of element.
> 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
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.
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 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.
> 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.
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:
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.
<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
> The UA - UserAgent StyleSheet (Browsers default stylesheet) defines CSS [hidden] { display:none }
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.)
I'm a bit miffed about the dash. I wish it was a colon. Then well established XML could be simply name-spaced in, and then either styled with css and enhanced with JS. I suspect it wouldn't be that difficult to write something for nginx or apahce that simply converted the colon to a hyphen. Oh well, it cannot be 1999 forever.
Why is this not default practice?
Mainly because it isn't semantic and breaks accessibility features. If you find yourself writing layouts like this you're probably ignoring a bunch of useful stuff like <aside> <article> <menu> etc. Unless you manually configure it yourself, screen readers won't know what's important to read, tabindex won't know where to jump around, and form fields won't know what values to offer.
> isn't semantic
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.
> I don't know if I'd call it breakage to just... not use them where they should be used.
Accessibility only has 2 states: "Working" and "Broken", there's no third "I didn't bother".
> It's certainly better than calling everything a div.
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.
> 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
This article is written for web developers. I’m not sure who you think you are addressing with this comment.
In any case - the argument is a weak one. To the extent people make the mistake you allege they can make it with classed div and span tags as well and I’ve seen this in practice.
> 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
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.
I've seen <span class=italics>, and it made me want to break things.
That is a strawman. I never said everyone who uses classes perfectly uses semantic elements.
My point is that if you are using <div class=my-element> you don't have to change your .my-element CSS selector or JS selection code to improve your code to <p class=my-element>. If you are using <my-element> it is much more work to change your selectors and now you have two ways of doing things depending on if you are using a native semantic element or a div (either a tag selector or class selector). You have made your styling code depend on your element choice which makes it harder to change.
> For semantic purposes
But semantic purposes are not all possible purposes.
> > If you find yourself writing layouts like this you're probably ignoring a bunch of useful stuff like <aside> <article> <menu> etc.
> It's certainly better than calling everything a div.
Yes but it's worse than <aside> <article> <menu> etc. as the comment you are replying to mentions.
This example also shows a weakness of custom tags compared with using the class attribute. An element can have only single name but may have several classes. And as classes are unordered set, one cannot in general emulate that with several elements as the nesting introduces an order absent in the class list.
I’d argue it’s a strength. You still have classes and custom attributes to reach for when you want an (effectively) unordered set, the difference is just that you define some boundary that’s exclusive. This reflects reality. Some helper classes work together by just slapping them together, but component-like classes, like a toggle and a hero image, don’t. If you do want to combine them, you need to think about how, potentially rearchitect, and implement it whether you’re using classes or tag names.
Good use case for @container, @scope and :has(), where you forgo class definitions and use --custom-properties on the parent scope/container which are inherited downwards based on the existence of a scoped DOM pattern/container query, or 'upwards' by using a :has(child-selector) on the parent.
Although be sure to avoid too many :has(:nth-child(n of complex selector)) in case of frequent DOM updates.
[flagged]
Honestly it depends what you're doing. A tag name is only correct when it unambiguously specifies the content. As in, a header is just a header - there's no "dual nature" that we have to support by allowing multiple tag names. This means the ontology you're representing has to be "linear" - you can have more specific and less specific tags, but never a "fork" where you could really choose either more-specific tag in order to emphasise a different "part" of the tag. Classes should always be for secondary properties, which are not the main "essence" of the content.
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.
Not trying to be rude but to me that is the essence of composition which feels perfect to me
Hot take: div soup isnt bad because html isn't purely structural. It's a natural consequence of a poor design decision. Div soup is a consequence of the design decision to couple html elements to styling, state management, etc.
It made sense in 1996. It does not make sense now.
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.
I'm highly interested in approaches that utilize web grain in a balanced practical way. Do you have a framework/toolbelt or example sites to share? Would love to see.
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.Thanks for sharing, that’s an interesting framework. The self-closing tags are very nice.
Unfortunately, I don’t have anything public to show at the moment. Maybe I’ll blog about the approach some day.
Well, I hope to see it.
Why is this being downvoted? I'm baffled. The comment is coherent and relevant to the discussion at hand.
> And yes, I abuse the slot attribute even when I'm only using CSS, without JS.
In CSS, how do you target <div slot="hero-blurb"> based on the "hero-blurb" slot?
div[slot="hero-blurb"]?
Yes, though often I’ll omit the tag, and just target [slot=“hero-blurb”]. Depends on the situation.
That reminds me of BEM, where slow= is like the "element" within a parent "block".
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...
I used custom elements extensively in 2014 when support was not as widespread. I think it's a beautiful, elegant solution and I'm still a little bit bitter that React became as big as it was. Now everything "has" to be a SPA because developers want to use React, whereas most users would actually be better served with good 'ol HTML with some custom elements where needed.
> Now everything "has" to be a SPA because developers want to use React
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.
I’ve been getting into SSR with JSX as a template engine using kita. You still get full typescript analysis and composability. It beats any other SSR web templating system I’ve used.
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.
You do the crud app and then they want: just make this to edit inline. You do some Ajax api Call with a tiny js. Then you need more and more. Then you have a mess and you’d be better with react. I still can’t find a project id be better of without react. When I tried without it bite me very quickly.
Nothing wrong with JS. It all depends on whether you have a strong sense of the bounds of the project.
SPAs are early 2010s homie. SSR has been dominant for the past 5 years.
> I think it's a beautiful, elegant solution
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
What makes custom elements good is inrerop. I can use them in react, Vue, angular, svelte, solid, or just plain ol' server rendered html. I can switch out the internals entirely for a WC lib, or not, with nobody knowing or caring.
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)
> At least if you are in a position where your component might be used in many places.
I think someone once called them leaf components, and on this I agree.
They don't need to be leaf components to still have this strength. I've worked with design systems which have a <my-layout> component near the root which defines sidebar, header etc slots. This still works nicely with react, Vue etc
But I agree they tend to be better suited as "leafier" components
> I've worked with design systems which have a <my-layout> component near the root which defines sidebar, header etc slots.
Funnily enough this is exactly what original proposal of web components was against :)
Honestly I couldn't care less what the original proposal said! Things evolve. Utility is found in unforeseen places. That's the nature of ~everything. Personally I'm not a fan of that kind of component but not aligning with some original, preordained vision is a minor nit
You know what else can be used in all these contexts? Defined HTML elements
Not even sure what argument you're making here. A web component bundles one or more of: markup, styles, functionality. You can't do that with just html such that it's easily consumable in all the ways I mentioned.
As far as I can tell, the whole web components umbrella came into being because React/Vue got really popular, and the spec/browser people said hey let's bring the core common denominator of those into native HTML/JS, as if it would bring us closer to having native Vue/React. Which of course never happened, partly because HTML is fundamentally incapable of having anything but string attribute values, and partly because reactive DOM is basically a hard problem that can't or maybe shouldn't be solved natively.
> As far as I can tell, the whole web components umbrella came into being because React/Vue got really popular, and the spec/browser people said hey let's bring the core common denominator
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.
Right, and that proposal was withdrawn, and a new one, the one we have now, was proposed based on lessons learned from (or inspired by?) React/Vue. Maybe there was a common ancestor or general consensus about the techniques floating around in the community before proposal #1, but it was clearly inferior and flawed, and #2 was the one I'm talking about.
> That proposal was withdrawn
"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.
I would rather use semantic elements for the examples like the one in the article and use web components/custom elements where appropriate.
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
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
By the way, you can also do this pure CSS using the scripting media feature: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
I would suggest not using this as it's not compatible with NoScript
I didn't know this existed. Thanks for sharing! Very useful api
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 think you can do it fully in CSS these days! https://www.w3docs.com/tools/code-editor/13719
I modified `.blink` to `blink` so it will target the tag instead of the class and it seemed to work
This doesn't surprise me, I've seen a lot of cool stuff being done in CSS.
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.
> because the monsters who make browsers removed support for it
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.
Huh, I would have sworn that Internet Explorer had the blink tag at one point, but I think my parents had Netscape and then Mozilla pretty early so maybe that's what I'm confusing it with.
Regardless, I stand by my comment. Monsters! I want my browser to be obnoxious.
Never mind, Microsoft got you with <marquee>.
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.
KHTML added <marquee> support in October 2003 (commit 7bcdd98aa in the Chromium repository).
I have to say, that is some excellent sleuthing.
I think I remember reading articles about how to implement blink in IE using behaviors, some IE only thing that didn't take hold(?), Maybe this was around IE5.
IE was holding back the progress even before Chrome and Safari were a thing.
> IE was holding back the progress
Oh those times. IE accepted <table><tr><td><tr></table> whereas Nestscape demanded <table><tr><td></td></tr></table> and would just not render anything else - just blank grey
Humans loved it, when they had to type all this by hand, because missing /td would not kill your page.
Permissiveness won out.
I also remember the day JavaScript hit the net.
and all those "chat rooms" that did <meta refresh> to look live suddenly had no defence against this
<script>document.write('http://twistys.com/folder/porn.jpg')</script>
or alert bombs
Oh those times. <script>document.createElement("table").appendChild(document.createElement("table"))</script> would crash IE, and some similar stupidities could even cause a BSOD as late as Windows 98.
(I think that was one such incantation, but if it wasn’t quite that it was close.)
Talking about this, I am still sad Flash got removed from the web.
Nothing to replace it with to afaik.
Good riddance. I once had the honor of being featured together with many other artist on an HP website. It was implemented in Flash though, meaning it existed as a smallish rectangle in the middle of a website; within that rectangle you could click through to browse the exhibition one artwork at a time. This entailed that your path through the Flash app was not connected to the browser's address bar and exhibits did not get a URL of their own. When you wanted to direct others to your piece the only way was by giving them a "Japanese visitor's address", as in "go to this well-known named point (the domain name), from there walk west and when you see a tall black building, turn right and take the third alley to your left, I'm living in the fifth house down that alley".
Plenty to replace it with to afaik.
Well technically you can still use Flash via Ruffle, a WebAssembly-based emulator:
https://ruffle.rs/
Sites like Kongregate amd albinoblacksheep are using it to revive their old catalog.
Although Flash really sucked as a technology, it did inspire a lot of visual artistry on the web. Half of the cool stuff you saw on StumbleUpon was made with Flash by people who weren't proficient with JS/CSS, which weren’t capable enough to achieve the same results anyway.
I stand by that Flash was the most fun way to write software, especially games.
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.
Just keep using Flash? It's called Animate now. https://www.adobe.com/products/animate.html
I know, but since there’s not a great way to deploy and share stuff it’s not the same.
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.
You can export it as HTML/CSS/JS and upload it somewhere.
I haven’t tried that lately but when I tried that a few years ago it was terrible.
Flash was fun but it was never built for being responsive and handling desktop and mobile in one app. Everything was basically fixed layout. Adding in that responsiveness would have probably killed the "easy" part.
Really? Flash had been such an absolute pain for me for years, I was so happy when my bank stopped using it so I could uninstall the heck out of it.
I for one am glad that blink is no longer a thing, it's certainly behavior that should require more thought than a simple html element can provide.
I just kind of feel like removing it makes the internet less fun. 90's internet was basically a playground for geeky people to make things purely for fun, with basically no ambitions of making any money; people would host their own terrible web pages. My first real introduction to "programming" (other than making a turtle walk around) was when I was nine years old and bought "Make Your Own Web Page : A Guide for Kids" from my school, and this was something a nine year old kid could do because the web was easy and fun to program for. There weren't a billion JavaScript frameworks, CSS was new (if it was even supported), everything was done with tags and I loved it.
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 to satisfy shareholders.
Aye.
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, blue links that turned purple once clicked, 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.
You have me in tears...
> <main-article>
> <article-header>
> <article-quote>
> <quote-body>
Not the best example, because in this case, you could just use real HTML tags instead
If you use the predefined HTML tags you also get whatever default styling the browser decided is appropriate.
This is how you can set default styles for all your custom elements:
Amazing, I was literally just trying to see if I could figure out how to do this. Thanks!
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.
Nitpick: If a nonstandard element name contains a hyphen (and is otherwise a syntactically valid custom element name), the element's DOM object is an instance of HTMLElement, not HTMLUnknownElement.
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."
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:
It didn't take long before I realized I could just add any random tag, add it to my shim, and render it on any browser.[0]: https://idiallo.com/blog/revisiting-my-old-javascript
I'm sure that's how the popular html5shim used to work, too. I remember looking at the source out of curiosity.
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.
So, the article doesn't discuss this, but there's actually a really good reason to make up and use custom elements: the browser can hydrate their dynamic behaviour automatically. For example, suppose you have:
And you have some JS that handles the expander's behaviour: This will work fine for `.expander` divs that are already in the page when the event handler is set up. But suppose you dynamically load new expander divs, what then? Your event handler is not going to retroactively set up their click listeners too.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.this.querySelector will return nothing when you define this Web Component before (light)DOM is parsed, because the connectedCallback fires on the opening tag.
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...
Well, that's why I include JS files at the bottom of my HTML body, to make sure to avoid exactly this problem: https://github.com/yawaramin/dream-html-ui/blob/92f2dfc51b75...
One drawback.
► 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
Beware that connectedCallback runs _every time_ a custom element is added to the dom. So you should make sure to only add event listeners once by tracking internally if the element was already initialized.
Thanks, that's good to know. In some contexts I don't think a custom element is ever added to the DOM more than once, eg in htmx I am responding with HTML markup which is then injected into the page and then just kept there, possibly 'forever' or at least until it is replaced by some new markup from a new response.
That's good to know, and I even did say that custom UX widgets are a case where custom tag names makes more sense conceptually.
I'm really just pushing back on the idea of using them for CSS formatting purposes of general text and layout instead of classes.
Yes, the hydration behavior of custom elements is nice. You don’t even need to do anything special with JS bundle loading.
Simply render your <element> (server-side is fine) and whenever the JavaScript downloads and executes your custom elements will mount and do their thing.
> no real reason
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).
Why would it create confusion? Because you're not familiar with it? Things change..
Because there are so many native elements to keep track of now.
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.
There's a very clear rule for it: if it contains a dash it's a custom element
That rule doesn't work in reverse. If there's no dash it could be either.
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.
Just use classes. That's what they're there for.
Only native elements can be a single word, you can't create a custom elements without a dash.
Let's be clear: this whole conversation isn't about custom elements. This is about formatting. Not web components.
You just use it (single word) and style it (CSS) and it works. You don't have to "create" anything.
So nothing's stopping anyone from using single-word elements. There's another comment here defending exactly that:
https://news.ycombinator.com/item?id=46418090
But it's bad practice. Just use classes. It's literally what they are designed for.
Aha fair enough, but yeah browsers often allow invalid HTML to just work. But that doesn't mean that the valid usage is somehow flawed. I can understand that the dash can be a bit of a weird rule if you're new to HTML. But I think it's an elegant way to allow users to create custom tags and have readable compact semantic HTML.
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.
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.
I just evaluated Lit for work and while we didn't go with it, it was very nice. I love the base custom elements API regardless of using Lit or not, turns out that's all you really need to make intricate UIs that feel seamless.
Something about Lit/web components that's not written clearly on the label is the hoops you have to jump through to style elements. If you're using tailwind in the whole app, you just want to pull it into your custom elements without much boilerplate. My main app compiles a single minified app.css, it felt not so modular to now include that in every single component. The alternative is create a subclass that injects tailwind into Lit components. It'd be perfect it just had a switch to inherit everything the page already has.
> It'd be perfect it just had a switch to inherit everything the page already has.
It does! <https://lit.dev/docs/components/shadow-dom/>
By default, Lit renders into 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.
However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:
Then you define your shared styles in `themeStyles`, which is shared across all components you wish to have the same theme.I also made a simple lib to make it easy to implement common styles in your Lit components:
https://github.com/gitaarik/lit-style
oh nice! I didn't know that you can just make it use light dom.
And that's what it takes! I like using tailwind/utility classes so for the styles I'd need to have layers of compiled css files rather than one giant one.The major downside of using light DOM is that elements cannot compose neatly since there's no delineating between what the component itself rendered and child content.
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
There's a long standing standards issue for this: https://github.com/WICG/webcomponents/issues/909
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.
Interesting, I'd be curious to know why you all decided not to go with it if you're open to sharing! Minimally to know if I should look at any other promising frameworks.
I see a good case for my company to use Lit for creating complex components such as highly interactive panels/widgets to be shared between React/Angular apps in our large ecosystem. However the decision was: 1. Prefer sharing plain JS/TS over framework code so try that first and 2. if the component is so complex and tricky to get right, it probably needs to be re-implemented in each framework anyways (or some sort of wrapper)
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.
Ah yeah, definitely a much different equation when introducing this across many apps as a shared component library. Mixing different DOM abstractions together could get tricky for sure.
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!
What did you go with?
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.)
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
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...
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.
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.
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
><body>
<CustomElement>Hello</CustomElement><!-- Custom element in the XHTML namespace -->
<ns1:CustomElement>Hello</ns1:CustomElement>
<ns2:CustomElement>Hello</ns2:CustomElement>
<style type="text/css">
</style></body>
</html>
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/clock</built-in> <keyword>:cputime</keyword> <keyword>:tuple</keyword>)) ```
That's kinda cool but the article addresses a major concern with this strategy that is not addressed here. Which is that many of these tags (e.g. <special>, <keyword>, etc) might someday become part of the HTML standard.
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
Fair, I had a collision with <math> for a month before someone else noticed some minor error.
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
Not sure about you, but I personally prefer my websites not to be able to be plagiarised by AI
ChatGPT makes the content visible and the author invisible. Why should anyone optimize for AI consumption?
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">`.
I'd ship it with <card> in my own apps ("my own apps" in bold)
That is ... XML without schema but with CSS support. Cool.
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.
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/
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 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:
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."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.
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 find this fun and whimsical, but surely it’s an accessibility nightmare.
No difference from using a div/span.
simply only ever use this to replace <span> or <div>
aria tags for days
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)
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 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.
> 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?
HTML 5 still gets new features all the time: https://github.com/whatwg/html
But they'll never add new standard tags with hyphens.
> but I'm afraid we got html5 and just stopped there.
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.
Been doing this for over twenty years now
You name it, it works wonders and make my life easier. Of course I am a lone developer so I don't care.You can check in this demo some custom tags used sparingly https://my.adminix.app/demo
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.
> And a <div> is just a <span> with display block…
It's a bit more subtle than 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 and this is very in the deep end, I can't think of the last time I've consciously thought of this stuff.
https://html.spec.whatwg.org/#the-span-element
https://html.spec.whatwg.org/#the-div-element
https://html.spec.whatwg.org/#content-models
It's one of my favorite little tricks. I use it when I'm building applications that have a lot of nested "contexts" and its not just styling/layout. Makes it easier to search for and jump to these contexts and mentally parse them. But I use it sparingly. It gets out of hand fast if you start doing <parent-nested-2ndchild-list-item>.
11 year old example (but still funny): https://github.com/ebidel/html5demos/blob/master/html5-demos...
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.
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.
A more common alternative to counting divs would be CSS classnames or (for unique elements on the page) IDs. You'd do `document.querySelector('.my-class')` to locate `<div class="my-class">` or similar, rather than using the fact that e.g. something is nested 3 divs inside <body>.
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.
Sorry, I didn't mention class names because the article explicitly did and I assumed that my aversion to the extra typing would be presumed by a reader of my comment. My mistake.
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. I was talking about the manual editing (in vim, as I mentioned), rather than any dynamic query selectors. Make more sense?
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/
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:
With custom tags, that is not possible because variable names cannot have hyphens in them.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."
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)
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.
There is a CSS library that utilizes this behavior: https://github.com/doeixd/CSS-Tags
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.)
There is N-th child selector with filter, for example you can write :nth-child(3 of .red)
https://waspdev.com/articles/2025-06-29/css-features-web-dev...
Cool! I guess this now also makes nth-of-type superfluous.
IMHO this also makes custom tags no longer very useful beyond custom HTML components (JS is also required for that). The standard tags provide good semantics, SEO and accessibility out of the box.
Also, probably a good way to give LLMs more context compared to “div soup”
I find that deviating from standards has ways of triggering growing pains.
loving it (my tag emoji vanished, the tag is, "Commonly used to represent a --tag, metadata, tag as well as for those various senses of labelling")
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.
web components are terrible and should not be used for modern development with the exception of very nieche use cases that require sandboxing
Custom elements are web components, it's literally what the article is about
If this works, then the point of having standards, is just for screen readers??
Isn't this the basis for every web framework? E.g., Vue Templates?
Frameworks generally change those to standart tags at build time. Vue can be used without a build step so it indeed uses custom tags for components in that scenario but it is not very common to use Vue without a build step.
the comments here informing us they default to behaving like <span> instead of like <div> is the biggest disappointment of my day so far
I think it makes sense that if HTML detects an unknown element that it doesn't give it block styling automatically. Only if you specifically specified it for that type of element.
Inline styling is kind of the default in HTML.
See my other comment: you can set default styles using
:where(:not(:defined)) { display: block }
> 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'm very curious how screen readers would handle this. what a terrible idea
Presumably exactly the same as a div/span.
[dead]
[dead]
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.
See https://news.ycombinator.com/item?id=46417607
Why is this?
Hmmmm.
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.
> 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.
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:
> I avoid the new HTML tags…
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.