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]
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).
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 :)
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>
It seems to me that there is a lot less room for error when not using IDs, so I always wrap the input. My pages use a client-side webcomponent to inject fragments of HTML into the page (navbar, footer, etc), and using IDs almost always cause conflicts in the end, so I avoid ID attributes in all but a few very rare instances.
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.
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.
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.
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.
(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)
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.
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.
> 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 :-(
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 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.
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.
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.
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.
Subheadings are one of those little things I've wondered about the proper semantics for a million times and always end up doing something slightly different on the fly.
Worse, it has changed content rules and semantics in backward-incompatible ways. Meaning there are pages out there that used to be valid, but aren't anymore. And since HTML spills to EPub specs, I recall there were EPubs or EPub spec examples/test suites themselves having to change specifically, epubcheck being actually used for validation and hence directly noting this backward incompatibility.
In a nutshell, hgroup was originally criticized and rejected when W3C was still redacting HTML specs received from the loose group of browser devs and other people calling themselves "WHAT working group" because it paired headings of multiple ranks in a way that confused assistive technologies in browsers. But the first (and at the same time the last;) W3C HTML recommenndation created as unredacted WHAT WG spec snapshot under the W3C/WHATWG "memorandum of understanding" actually smuggled hgroup in. Then Steve Faulkner removed HTML outlining and the whole concept of sectioning roots that was part of Ian Hickson's vision of "HTML 5" for the longest time, but W3C never actually started a new recommendation process afterwards, and the charter for the HTML WG at W3C, Inc. has ended last year. See details at [1].
Arguably, with this change in 2023, we're now post-HTML5. But don't tell the people believing in a single "HTML 5 standard".
unlike the <blink> tag where younger people will just stare at you in a creepy extended unblinking gaze. it would be so much more satisfying if it still made them blink.
On mobile (Safari), the link to the article scrolls me down towards the bottom of the page by the iframe/red dot, making me think half the page was missing.
While complexity of web tech means there's usually some hidden nuance, that description on MDN seems pretty clear: a non-interactive (other than for navigation) iframe, ie an <a> element that's a preview.
Looks to me like it's intended as a link with preview, and part of the idea is that user agents could do a sort of animated transition morphing the preview into the content of the destination page.
Most people insist on only using one element, which is the element of last resort, according to MDN. This is our friend, the <div>.
The only use case I have for <div> is in a details/summary where there is no CSS to select the contents of a <details> element, excluding the <summary>.
Does this mean I use <section> instead of <div>, as a 'direct replacement'? Nope. When using CSS grid, there is no need for <div> wrappers around everything.
I do like to use the full HTML element set, and, with scoped CSS, to style the elements, rather than have loads of divs with loads of class attributes. It all looks so much neater, particularly if the unstyled CSS looks rather good.
This is a great approach. Just to add to it, you can also use custom elements in lieu of classes, such as:
<my-product>...</my-product>
Any tag with a hyphen is considered a custom element, which is completely valid HTML -- even without defining the element in JS.
This gives you a more descriptive `div`, and then instead of classes like `product-primary`, you can use semantic attributes, like `<my-product primary size="large">`. In combination with CSS nesting, you can get some great looking HTML and CSS with minimal markup/visual noise and no build step.
Commercial work is different to pet projects, and, given that I have been told off for using <address> before now, I am wary of making up mu own elements.
I quite like styling the attributes, which gets me half-way to what you describe. In ecommerce we have all kinds of extra attributes for marking up products, although you can ditch that and just have a chunk of JSON+LD these days.
What happens is that I end up with great document structure and human readable/writable HTML and no CSS preprocessor things needed. However, sometimes I have things such as lots of sections containing lots of articles that contain lots of sections. I might take your tip to write '<top-category>' for those top-level sections.
When styling the elements, you tend to use the full range of elements, so a list could be a <dl>, <ol> or <ul> even if it eventually just gets styled as an <ul>. Really, semantics needs to come first, even if the presentation is just normal stuff.
I keep finding code examples where people are doing more than just using divs, which means that I am feeling more confident flexing the whole HTML element LEGO set.
You do need a hyphen for a custom-tag. The HTML specs have guaranteed never to create a tag with a hyphen, so it prevents collisions with any future tag additions.
> I do like to use the full HTML element set, and, with scoped CSS, to style the elements, rather than have loads of divs with loads of class attributes. It all looks so much neater, particularly if the unstyled CSS looks rather good.
> The only use case I have for <div> is in a details/summary where there is no CSS to select the contents of a <details> element, excluding the <summary>.
Not to hand, for sharing here, but just try it with something like your CV, in neat HTML. Set yourself some rules to not use classes (for the lols, not out of ideological hatred) or divs (there is always a better element).
If you can't do it, there is probably more work to do with your document structure. Also try and always have a h1-h6 heading in your articles, sections, asides and even navs, at the top. Headings should not be in a sea of paragraphs, they should be at the top of a content sectioning element, nowhere else.
HTML elements are used to describe their content and not have anything to do with layout. While they often have common properties, these can be changed using CSS.
So use the element that best describes its content.
The story of XHTML is instructive to the field of software design. There are plenty of good resources on the web if you search why did XHTML fail?
HTML parsing at least is deterministic and fully specified, whereas XHTML, as an XML, leaves a number of syntax errors up to the parser and undefined.
Conforming software may detect and report an error and may recover from it.
While fatal errors should cause all parser to reject a document outright, this also leaves the end-user without any recovery of the information they care about. So XHTML leaves readers at a loss while failing to eliminating parsing ambiguity and undefined behavior.
Interestingly, it’s possible to encode an invalid DOM with XHTML while it’s impossible to do so in HTML. That means that XML/XHTML has given up the possibility of invalid syntax (by acting like it doesn’t exist) for the sake of inviting invalid semantics.
Interesting perspective, it makes me miss XHTML wayyy less. I was under the impression that XHTML (XML) was better specified and had less weirdness. I know HTML is now better specified but some of the things inherited from HTML 4 and before make no sense to me (optional closing times SOMETIMES, optional stuff everywhere).
HTML didn’t make sense to me until I realized it’s built on a state machine and its rules are based on what’s on the stack of open elements. For example, a number of tags trigger a rule to close open P elements or list items, and many end tags trigger a rule saying something like “close open elements until you’ve closed one with the same name as this tag.”
This, IMO, is a bigger reason to avoid regex and XML parsers for HTML documents. The rules aren’t apparent when thinking linearly about what strings appear after or before each other; they become clearer when thinking of HTML as a shorthand syntax for certain kinds of push and pop operations.
XHTML is easier to parse, but for well-formed documents pushes the complexity of invalid markup into the rendering side. For example, it’s well-formed to include a button inside a button, so XHTML browsers render exactly this, but it makes no sense from a UI perspective and strange things happen when invalid markup is sent in well-formed XML.
Very dismissive. Anyone not using <span> should take a second look. Of all the elements, this is the one to change font, size, color, etc. in any dynamic text without offsetting anything in your layout. Do you really want to throw your user's text inside a <div> inside your nice <div> layout? No.
Indeed, <span> is for inline elements what <div> is for block elements: a way to organize and apply styling.
With raw html/js it can also be used for targeting text changes.
what this comment section is missing is "hey, here are other pages that do the same thing is a slighty different way" (there must be tons!? I would enjoy and learn from those type of comments so much I that I'd shout, "this is a motherfucking comment section!" https://motherfuckingwebsite.com/
Both <marquee> and <blink> have never been part of any HTML specification since the beginning of time except, in marquee's case, it was included in the current spec for the whole purpose of marking it as obsolete.
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...
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
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 :)
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?
It seems to me that there is a lot less room for error when not using IDs, so I always wrap the input. My pages use a client-side webcomponent to inject fragments of HTML into the page (navbar, footer, etc), and using IDs almost always cause conflicts in the end, so I avoid ID attributes in all but a few very rare instances.Downside is that screen readers may not handle the implicit label as well as one with explicit for= on it.
https://www.w3.org/WAI/tutorials/forms/labels/
https://developer.mozilla.org/en-US/docs/Web/API/Popover_API...
> 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.
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.
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.
In this example “hi” will render with every one of the preceding formats applied.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.
"please accept from me this unpretentious bouquet of early-blooming" <plaintext>s
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....
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.
Also Oxygen was mentioned, but not Argon
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.
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.
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)
"The future" is part of "everything".
Looking at it again, I would still say that "prescient" would be more accurate, because:
IOW, when describing a car, for example So I'll still go with "prescient" being more accurate, in much the same way that "SUV is more accurate.[0]: https://codepen.io/plfstr/full/zYqQeRw
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.
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.
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.
Subheadings are one of those little things I've wondered about the proper semantics for a million times and always end up doing something slightly different on the fly.
<hgroup> was officially added to the HTML spec in 2018 [1]
It was deprecated in the W3C spec but not from the WHATWG spec, before they were merged.
[1]: https://html.spec.whatwg.org/#the-hgroup-element
In a nutshell, hgroup was originally criticized and rejected when W3C was still redacting HTML specs received from the loose group of browser devs and other people calling themselves "WHAT working group" because it paired headings of multiple ranks in a way that confused assistive technologies in browsers. But the first (and at the same time the last;) W3C HTML recommenndation created as unredacted WHAT WG spec snapshot under the W3C/WHATWG "memorandum of understanding" actually smuggled hgroup in. Then Steve Faulkner removed HTML outlining and the whole concept of sectioning roots that was part of Ian Hickson's vision of "HTML 5" for the longest time, but W3C never actually started a new recommendation process afterwards, and the charter for the HTML WG at W3C, Inc. has ended last year. See details at [1].
Arguably, with this change in 2023, we're now post-HTML5. But don't tell the people believing in a single "HTML 5 standard".
[1]: https://sgmljs.net/blog/blog2303.html
It was only deprecated in the W3C specification, not the WHATWG specification.
But now it's back in good standing: https://www.tpgi.com/subheadings-subtitles-alternative-title...
Perhaps it was re-added?
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/po...
(And experimental)
The only use case I have for <div> is in a details/summary where there is no CSS to select the contents of a <details> element, excluding the <summary>.
Does this mean I use <section> instead of <div>, as a 'direct replacement'? Nope. When using CSS grid, there is no need for <div> wrappers around everything.
I do like to use the full HTML element set, and, with scoped CSS, to style the elements, rather than have loads of divs with loads of class attributes. It all looks so much neater, particularly if the unstyled CSS looks rather good.
<my-product>...</my-product>
Any tag with a hyphen is considered a custom element, which is completely valid HTML -- even without defining the element in JS.
This gives you a more descriptive `div`, and then instead of classes like `product-primary`, you can use semantic attributes, like `<my-product primary size="large">`. In combination with CSS nesting, you can get some great looking HTML and CSS with minimal markup/visual noise and no build step.
I quite like styling the attributes, which gets me half-way to what you describe. In ecommerce we have all kinds of extra attributes for marking up products, although you can ditch that and just have a chunk of JSON+LD these days.
What happens is that I end up with great document structure and human readable/writable HTML and no CSS preprocessor things needed. However, sometimes I have things such as lots of sections containing lots of articles that contain lots of sections. I might take your tip to write '<top-category>' for those top-level sections.
When styling the elements, you tend to use the full range of elements, so a list could be a <dl>, <ol> or <ul> even if it eventually just gets styled as an <ul>. Really, semantics needs to come first, even if the presentation is just normal stuff.
I keep finding code examples where people are doing more than just using divs, which means that I am feeling more confident flexing the whole HTML element LEGO set.
From a discussion on HN a few days ago, I bookmarked this: https://github.com/dbohdan/classless-css
For the most common types of front-end work one needs to do, classless CSS is enough.
div > *:not(summary)
If you can't do it, there is probably more work to do with your document structure. Also try and always have a h1-h6 heading in your articles, sections, asides and even navs, at the top. Headings should not be in a sea of paragraphs, they should be at the top of a content sectioning element, nowhere else.
(e.g., a toolbar with with left- and right- justified elements, among which is an expanding searchbox).
So use the element that best describes its content.
That's XHTML which is XML. HTML does not use and does not need a closing slash and never has in any HTML specification.
https://html.spec.whatwg.org/dev/text-level-semantics.html#t...
HTML parsing at least is deterministic and fully specified, whereas XHTML, as an XML, leaves a number of syntax errors up to the parser and undefined.
While fatal errors should cause all parser to reject a document outright, this also leaves the end-user without any recovery of the information they care about. So XHTML leaves readers at a loss while failing to eliminating parsing ambiguity and undefined behavior.Interestingly, it’s possible to encode an invalid DOM with XHTML while it’s impossible to do so in HTML. That means that XML/XHTML has given up the possibility of invalid syntax (by acting like it doesn’t exist) for the sake of inviting invalid semantics.
This, IMO, is a bigger reason to avoid regex and XML parsers for HTML documents. The rules aren’t apparent when thinking linearly about what strings appear after or before each other; they become clearer when thinking of HTML as a shorthand syntax for certain kinds of push and pop operations.
XHTML is easier to parse, but for well-formed documents pushes the complexity of invalid markup into the rendering side. For example, it’s well-formed to include a button inside a button, so XHTML browsers render exactly this, but it makes no sense from a UI perspective and strange things happen when invalid markup is sent in well-formed XML.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...
Based on my tests just now, <blink> no longer blinks in today’s browsers but <marquee> still scrolls happily.
but hey, "use the platform"
Nice Work!