Don't forget these tags to make HTML work like you expect
blog.jim-nielsen.com132 points by FromTheArchives 4 hours ago
132 points by FromTheArchives 4 hours ago
Fun fact: both HN and (no doubt not coincidentally) paulgraham.com ship no DOCTYPE and are rendered in Quirks Mode. You can see this in devtools by evaluating `document.compatMode`.
I ran into this because I have a little userscript I inject everywhere that helps me copy text in hovered elements (not just links). It does:
[...document.querySelectorAll(":hover")].at(-1)
to grab the innermost hovered element. It works fine on standards-mode pages, but it's flaky on quirks-mode pages.
Question: is there any straightforward & clean way as a user to force a quirks-mode page to render in standards mode? I know you can do something like:
document.write("<!DOCTYPE html>" + document.documentElement.innerHTML);
but that blows away the entire document & introduces a ton of problems. Is there a cleaner trick?
I know this was a joke:
<div id="root"></div>
<script src="bundle.js"></script>
<main>...</main>
I’m not a blind person but I was curious about once when I tried to make a hyper-optimized website. It seemed like the best way to please screen readers was to have the navigation HTML come last, but style it so it visually comes first (top nav bar on phones, left nav menu on wider screens).
Wouldn’t that run afoul of other rules like keeping visual order and tab order the same? Screen reader users are used to skip links & other standard navigation techniques.
Anyone else prefer to use web components without bundling?
I probably should not admit this, but I have been using Lit Elements with raw JavaScript code. Because I stopped using autocomplete awhile ago.
I guess not using TypeScript at this point is basically the equivalent for many people these days of saying that I use punch cards.
37 Signals [0] famously uses their own Stimulus [1] framework on most of their products. Their CEO is a proponent of the whole no-build approach because of the additional complexity it adds, and because it makes it difficult for people to pop your code and learn from it.
[0]: https://basecamp.com/ [1]: https://stimulus.hotwired.dev/
Dunno. You can build without minifying if you want it to be (mostly) readable. I wouldn’t want to give up static typing again in my career.
Can't say I generally agree with dropping TS for JS but I suppose it's easier to argue when you are working on smaller projects. But here is someone that agrees with you with less qualification than that https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
I was introduced to this decision from the Lex Fridman/DHH podcast. He talked a lot about typescript making meta programming very hard. I can see how that would be the case but I don't really understand what sort of meta programming you can do with JS. The general dynamic-ness of it I get.
I often reach for the HTML5 boilerplate for things like this:
https://github.com/h5bp/html5-boilerplate/blob/main/dist/ind...
There is some irony in then-Facebook's proprietary metadata lines being in there (the "og:..." lines). Now with their name being "Meta", it looks even more proprietary than before.
Maybe the name was never about the Metaverse at all...
Are they proprietary? How? Isn't open graph a standard and widely implemented by many parties, including many open source softwares?
They're not, at all. It was invented by Facebook, but it's literally just a few lines of metadata that applications can choose to read if they want.
Being invented by $company does preclude it from being a standard.
https://en.wikipedia.org/wiki/Technical_standard
> A technical standard may be developed privately or unilaterally, for example by a corporation, regulatory body, military, etc.
PDF is now an international standard (ISO 32000) but it was invented by Adobe. HTML was invented at the CERN and is now controlled by W3C (a private consortium). OpenGL was created by SGI and me maintained by the Khronos Group.
All had different "ownership" paths and yet I'd say all of them are standards.
> <html lange="en">
s/lange/lang/
> <meta name="viewport" content="width=device-width,initial-scale=1.0">
Don’t need the “.0”. In fact, the atrocious incomplete spec of this stuff <https://www.w3.org/TR/css-viewport-1/> specifies using strtod to parse the number, which is locale dependent, so in theory on a locale that uses a different decimal separator (e.g. French), the “.0” will be ignored.
I have yet to test whether <meta name="viewport" content="width=device-width,initial-scale=1.5"> misbehaves (parsing as 1 instead of 1½) with LC_NUMERIC=fr_FR.UTF-8 on any user agents.
Wow. This reminds me of Google Sheets formulas, where function parameters are separated with , or ; depending on locale.
Not to mention the functions are also translated to the other language. I think both these are the fault of Excel to be honest. I had this problem long before Google came around.
And it's really irritating when you have the computer read something out to you that contains numbers. 53.1 km reads like you expect but 53,1 km becomes "fifty-three (long pause) one kilometer".
> Not to mention the functions are also translated to the other language.
This makes a lot of sense when you recognize that Excel formulas, unlike proper programming languages, aren't necessarily written by people with a sufficient grasp of the English language, especially when it comes to more abstract mathematical concepts, which aren't taught in secondary English language classes at school, but it in their native language mathematics classes.
Not sure if this still is the case, but Excel used to fail to open CSV files correctly if the locale used another list separator than ',' – for example ';'.
Given that world is about evenly split on the decimal separator [0] (and correspondingly on the thousands grouping separator), it’s hard to avoid. You could standardize on “;” as the argument separator, but “1,000” would still remain ambiguous.
[0] https://en.wikipedia.org/wiki/Decimal_separator#Conventions_...
Try Apple Numbers, where even function names are translated and you can’t copy & paste without an error if your locale is, say, German.
aha, in Microsoft Excel they translate even the shortcuts. The Brazilian version Ctrl-s is "Underline" instead of "Save". Every sheet of mine ends with a lot of underlined cells :-)
Oh, good to know that it depends on locale, I always wondered about that behavior!
The behaviour predates Google Sheets and likely comes from Excel (whose behavior Sheets emulate/reverse engineer in many places). And I wouldn't be surprised if Excel got it from Lotus.
Note that <html> and <body> auto-close and don't need to be terminated.
Also, wrapping the <head> tags in an actual <head></head> is optional.
You also don't need the quotes as long the attribute doesn't have spaces or the like; <html lang=en> is OK.
(kind of pointless as the average website fetches a bazillion bytes of javascript for every page load nowadays, but sometimes slimming things down as much as possible can be fun and satisfying)
This kind of thing will always just feel shoddy to me. It is not much work to properly close a tag. The number of bytes saved is negligible, compared to basically any other aspect of a website. Avoiding not needed div spam already would save more. Or for example making sure CSS is not bloated. And of course avoiding downloading 3MB of JS.
What this achieves is making the syntax more irregular and harder to parse. I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. It would greatly simplify browser code and HTML spec.
Implicit elements and end tags have been a part of HTML since the very beginning. They introduce zero ambiguity to the language, they’re very widely used, and any parser incapable of handling them violates the spec and would be incapable of handling piles of real‐world strict, standards‐compliant HTML.
> I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient.
They (W3C) tried that with XHTML. It was soundly rejected by webpage authors and by browser vendors. Nobody wants the Yellow Screen of Death. https://en.wikipedia.org/wiki/File:Yellow_screen_of_death.pn...
> It would greatly simplify browser code and HTML spec.
I doubt it would make a dent - e.g. in the "skipping <head>" case, you'd be replacing the error recovery mechanism of "jump to the next insertion mode" with "display an error", but a) you'd still need the code path to handle it, b) now you're in the business of producing good error messages which is notoriously difficult.
Something that would actually make the parser a lot simpler is removing document.write, which has been obsolete ever since the introduction of the DOM and whose main remaining real world use-case seems to be ad delivery. (If it's not clear why this would help, consider that document.write can write scripts that call document.write, etc.)
You're not alone, this is called XHTML and it was tried but not enough people wanted to use it
oh man, I wish XHTML had won the war. But so many people (and CMSes) were creating dodgy markup that simply rendered yellow screens of doom, that no-one wanted it :(
i'm glad it never caught on. the case sensitivity (especially for css), having to remember the xmlns namespace URI in the root element, CDATA sections for inline scripts, and insane ideas from companies about extending it further with more xml namespaced elements... it was madness.
I'll copy what I wrote a few days ago:
The fact XHTML didn't gain traction is a mistake we've been paying off for decades.
Browser engines could've been simpler; web development tools could've been more robust and powerful much earlier; we would be able to rely on XSLT and invent other ways of processing and consuming web content; we would have proper XHTML modules, instead of the half-baked Web Components we have today. Etc.
Instead, we got standards built on poorly specified conventions, and we still have to rely on 3rd-party frameworks to build anything beyond a toy web site.
Stricter web documents wouldn't have fixed all our problems, but they would have certainly made a big impact for the better.
And add:
Yes, there were some initial usability quirks, but those could've been ironed out over time. Trading the potential of a strict markup standard for what we have today was a colossal mistake.
Yeah, I remember, when I was at school and first learning HTML and this kind of stuff. When I stumbled upon XHTML, I right away adapted my approach to verify my page as valid XHTML. Guess I was always on this side of things. Maybe machine empathy? Or also human empathy, because someone needs to write those parsers and the logic to process this stuff.
I agree for sure, but that's a problem with the spec, not the website. If there are multiple ways of doing something you might as well do the minimal one. The parser will have always to be able to handle all the edge cases no matter what anyway.
You might want always consistently terminate all tags and such for aesthetic or human-centered (reduced cognitive load, easier scanning) reasons though, I'd accept that.
<html>, <head> and <body> start and end tags are all optional. In practice, you shouldn’t omit the <html> start tag because of the lang attribute, but the others never need any attributes. (If you’re putting attributes or classes on the body element, consider whether the html element is more appropriate.) It’s a long time since I wrote <head>, </head>, <body>, </body> or </html>.
Didn't know you can omit <head> .. </head> but I prefer for clarify to keep them.
Do you also spell out the implicit <tbody> in all your tables for clarity?
I do.
`<thead>` and `<tfoot>`, too, if they're needed. I try to use all the free stuff that HTML gives you without needing to reach for JS. It's a surprising amount. Coupled with CSS and you can get pretty far without needing anything. Even just having `<template>` with minimal JS enables a ton of 'interactivity'.
> <!doctype html> is what you want for consistent rendering. Or <!DOCTYPE HTML> if you prefer writing markup like it’s 1998. Or even <!doCTypE HTml> if you eschew all societal norms. It’s case-insensitive so they’ll all work.
And <!DOCTYPE html> if you want polyglot (X)HTML.
<meta name="viewport" content="width=device-width,initial-scale=1.0">
The "without meta utf-8" part of course depends on your browser's default encoding.
What mainstream browsers aren't defaulting to utf-8 in 2025?
I spent about half an hour trying to figure out why some JSON in my browser was rendering è incorrectly, despite the output code and downloaded files being seemingly perfect. I came to the conclusion that the browsers (Safari and Chrome) don't use UTF-8 as the default renderer for everything and moved on.
This should be fixed, though.
html5 does not even allow any other values in <meta charset=>. I think you need to use a different doctype to get what the screenshot shows.
While true, they also require user agents to support other encodings specified that way: https://html.spec.whatwg.org/multipage/parsing.html#characte...
Another funny thing here is that they say “but not limited to” (the listed encodings), but then say “must not support other encodings” (than the listed ones).
[dead]
It's 2025, the end of it. Is this really necessary to share?
When sharing this post on his social media accounts, Jim prefixed the link with: 'Sometimes its cathartic to just blog about really basic, (probably?) obvious stuff'
Feels even more important to share honestly. It's unexamined boilerplate at this point.
Every day you can expect 10000 people learning a thing you thought everyone knew: https://xkcd.com/1053/
To quote the alt text: "Saying 'what kind of an idiot doesn't know about the Yellowstone supervolcano' is so much more boring than telling someone about the Yellowstone supervolcano for the first time."
XKCD 1053 is a way of life. I think about it all the time, and it has made me a better human being.