Every HTML Element
129 comments
·January 25, 2025eieio
I like this!
It's fun to compare it to "A blog post with every HTML element" [1][2], which gets at a (very!) similar thing but in a very different way. This post primary shows, and is a little more chaotic (meant positively!) whereas the other post is much more prose and explanation heavy (also good, but very different).
[1] https://www.patrickweaver.net/blog/a-blog-post-with-every-ht...
[2] HN discussion: https://news.ycombinator.com/item?id=37104742
wxw
Whoa! I'm a big fan of yours. You've really inspired me to think more creatively about the web/software. Thanks a ton, I'm glad this reached you.
eieio
Ah well hello! I'm not sure I've been recognized like that on the internet before. Thank you, that makes me very happy!
From your website it looks like we're in the same city; feel free to shoot me an email (mine is in my profile) if you'd like to grab coffee sometime :)
lelanthran
After looking at the source for this, I have a tangential question (feel free to answer even if you aren't the OP):
Whats the advantage of creating a separate `label` element before/after the input and using `for=` compared to simply wrapping the target input in the label element, like the code snippet below?
<label>
Your Name?
<input />
</label>
kevindamm
Upside (of implicit labels) is that there's no more gap and you can avoid the exclusivity of `id` attributes (as you mention).
Downside is that screen readers may not handle the implicit label as well as one with explicit for= on it.
assimpleaspossi
Note that the <input> tag does not need and does not use a closing slash and never has in any HTML standard: https://html.spec.whatwg.org/dev/input.html#the-input-elemen...
rav
No love for the <plaintext> tag? "The <plaintext> HTML element renders everything following the start tag as raw text, ignoring any following HTML. There is no closing tag, since everything after it is considered raw text." - it's my favorite obscure deprecated HTML tag.
dmsnell
Fun fact: this is very close but slightly inaccurate. I used to think this is how it worked before scrutinizing a rule in the HTML tree-building specification.
The tag leads the parser to interpret everything following it as character data, but doesn’t impact rendering. In these cases, if there are active formatting elements that would normally be reconstructed, they will after the PLAINTEXT tag as well. It’s quite unexpected.
<a href="https://news.ycombinator.com"><b><i><u><s><plaintext>hi
https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Ca...
After I discovered this the note in the spec was updated to make it clearer.
https://html.spec.whatwg.org/multipage/parsing.html#:~:text=A start tag whose tag name is "plaintext"assimpleaspossi
It's not deprecated. It's obsolete and totally removed from the HTML standard since HTML4.
kisonecat
I'm terrified of opening a paren andforgetting to close it! How terrifying to find a tagged paren that cannot be closed!
"please accept from me this unpretentious bouquet of early-blooming" <plaintext>s
layer8
It was an easy way to use an existing plain-text document where HTML was expected.
https://datatracker.ietf.org/doc/html/draft-ietf-html-spec-0...
The PLAINTEXT element was replaced by the LISTING element (which was itself deprecated in HTML 3.2): https://datatracker.ietf.org/doc/html/rfc1866#section-5.5.2....
filcuk
What in the world was the intended use for that?
soheil
same as <pre no?
hn_acker
The <dialog> element says "This is a modal dialog displayed using just HTML." but that's a bit misleading because the dialog opens using JavaScript `document.getElementById('my-dialog').showModal()` in the onclick attribute of the relevant button.
worble
Which is strange because you absolutely can open dialogs without javascript with the popover attribute
https://developer.mozilla.org/en-US/docs/Web/API/Popover_API...
robertoandred
The Popover API only makes non-modal popups.
worble
Yes, but in the article I posted:
> Popovers created using the Popover API are always non-modal. If you want to create a modal popover, a <dialog> element is the right way to go.
> You can turn a <dialog> element into a popover (<dialog popover> is perfectly valid) if you want to combine popover control with dialog semantics.
idoubtit
No, a <dialog> element will be displayed at page load if it has the "open" attribute. There is no need for JS.
The usual handling is with the JS API, but it's possible to handle it with CSS only. For instance, display the modal window only if a checkbox is checked.
sigzero
Correct, it is only modal if JavaScript is used.
joshdavham
I like that you included the <ruby> tag! I really wish more pages would use them when rendering Chinese/Japanese characters in English text.
fsckboy
(your comment is very minimally informative, containing 1 bit of information: "there is something to learn about ruby". Searching "show source", "hidden gems" on OP's page marks the ruby spot)
and looking up the <ruby> tag:
https://interactive-examples.mdn.mozilla.net/pages/tabbed/ru...
The <ruby> HTML element represents small annotations that are rendered above, below, or next to base text, usually used for showing the pronunciation of East Asian characters. It can also be used for annotating other kinds of text, but this usage is less common.
The term ruby originated as a unit of measurement used by typesetters, representing the smallest size that text can be printed on newsprint while remaining legible.
burgerrito
Oh wow, TIL the HTML element for furigana is <ruby>
efilife
I think it's very clear what he meant
TZubiri
Except this custom one I just invented that I implement in my custom browser
ruined
ive been demaking html elements by removing them from my custom browser so it evens out
TZubiri
But I didn't demark them so they are still elements.
Also Oxygen was mentioned, but not Argon
somat
Raises the question, how far can you get using only custom elements and css?
It sometimes appears that the modern ideal is to not have an element "do" anything on it's own and depend on the css to define it's purpose. But we still have a lot of historical baggage we are carrying around.
lelanthran
> Raises the question, how far can you get using only custom elements and css?
I am so glad to see someone use "raises the question" correctly instead of using "begs the question" which does not mean "raise the question".
In response to your question - you'd be surprised if you have a few (3-4) webcomponents for the most common needs in front-end; things like client-side includes, etc.
In fact, with just client-side includes you get 50% of what a front-end framework gives you (ability to create reusable and standalone components).
Of course then you spend the time you won in ditching the framework to figure out ways to pierce the shadowroot so you can apply your global styles to the component :-(
Ask me how I know.
byearthithatius
Too bad OP is not omniscient and capable of predicting your made up tags
lelanthran
> Too bad OP is not omniscient and capable of predicting your made up tags
I think a more accurate word here would be "prescient".
"Omniscient" means knowing everything, but I believe that "everything" doesn't include "everything now and in the future.
"Prescient" means knowing future events, i.e. "predicting"
(Emphasis mine)
riffraff
That's obviously up to your definition, but omniscience as commonly understood as an attribute of the Christian God is also knowledge of future events (which is why it's usually argued that it conflicts with free will).
"The future" is part of "everything".
null
null
Isognoviastoma
It's impressing that browser can display many levels of recursive iframe.
queueueue
I've counted 18! The next one was blank.
bbx
Relevant: https://htmlreference.io/
Neuronaut
The HTML Tags Memory Test [0] game refers to 114 tags. Your link got 113. I wonder what's missing?
dmsnell
The memory test is missing some deprecated and non-conforming elements. The HTML spec doesn’t have a single comprehensive list either, so it can be a little tricky to define or name “all” of the elements.
For example, there are elements like nextid or isindex which don’t have element definitions but which appear in the parsing rules for legacy compatibility. These are necessary to avoid certain security issues, but the elements should not be used and in a sense don’t exist even though they are practically cemented into HTML forever.
assimpleaspossi
Even more relevant: https://html.spec.whatwg.org/dev/semantics.html#semantics
hmmokidk
As a browser game enthusiast I will have you tried for missing canvas
butz
Canvas is stealthily hiding, as it has no content to display.
monroewalker
It’d be cool to have a gutter on the left with the html tag that appears for that line
assimpleaspossi
Don't know which tag you are talking about but gutters are CSS, not HTML. If you want a gutter, add one with CSS.
jy14898
They're talking about the post itself and its structure
mg
I wonder if it would be possible to do this in a way that the page shows its own source code.
Similar to:
https://no-gravity.github.io/html-quine/index.html
Could be tricky, because non-textual elements would probably have to be taken care of individually. For example a video would probably have to show a video of its own representation in code.
alwillis
This is very good: https://meiert.com/en/indices/html-elements/
jazzypants
I think it would be better to do a split panel so you could see the source and the end result side by side. This would eliminate the need for somehow showing the video and the source in the same place. You could even include the shadow DOM trees for a full explanation of how the browser renders complex tags like video.
fsckboy
for certain elements, a quinesque approach might not be that useful, but source could be displayed juxtaposed to results. (to show numbered lists, do you want to display the ol tags before the numbers (thus using fake numbers) or do you let ol numbering tags tag the elements with numbers and then show the source inside that?)
btw it really drives me crazy that browser implementors think that when I copy/paste a numbered list, I somehow don't want the numbers.
divbzero
Where is the good old…
<center>alignment with no CSS</center>assimpleaspossi
That's been obsolete for over 20 years: https://html.spec.whatwg.org/dev/obsolete.html#non-conformin...
edoceo
Bring back <blink> and <marquee>
amenghra
You can revive <blink> with a tiny bit of css: https://www.quaxio.com/blink.html
assimpleaspossi
You can't bring back something that never existed and both of those have never been part of any HTML standard. See my comment about this elsewhere.
For people interested in this sort of thing, I recently published a blog post looking at counts of HTML tags and their attribute values from a 2.9B page Common Crawl dataset. [1]
There's also a SQLite DB available to download of the top 1k tag+attr+value combinations. [2]
[1] https://webparsing.io/blog/hidden-in-html-parsing-page-layou... [2] https://webparsing.io/data/commoncrawl-2024-11-html-tags-att...