Live data from Hacker News

You can make up HTML tags

maurycyz.com

131–140 of 202 posts

Re: You can make up HTML tags

#131
post #127

Earlier quoted context omitted.

They don't need to be leaf components to still have this strength. I've worked with design systems which have a 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 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

Re: You can make up HTML tags

#132

Earlier quoted context omitted.

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 whereas Nestscape demanded 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 to look live suddenly had no defence against this document.wr…

Oh those times. document.createElement("table").appendChild(document.createElement("table")) 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.)

Re: You can make up HTML tags

#133
post #24

... a bunch more HTML ... 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: ... a bunch more HTML ...

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.

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.

Re: You can make up HTML tags

#134
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 and 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.)

Re: You can make up HTML tags

#135

Earlier quoted context omitted.

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

Re: You can make up HTML tags

#136
post #114

Earlier quoted context omitted.

> 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 implemente…

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 use…

You know what else can be used in all these contexts? Defined HTML elements

Re: You can make up HTML tags

#137

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…

I'm sure that's how the popular html5shim used to work, too. I remember looking at the source out of curiosity.

Re: You can make up HTML tags

#138
This is the basis of web components and of all popular frameworks. In this model, the only use for a plain 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...

Re: You can make up HTML tags

#139

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

[deleted]

Re: You can make up HTML tags

#140
post #80

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.
Post reply on HN