51–60 of 248 posts
It's 2025, the end of it. Is this really necessary to share?
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."
Earlier quoted context omitted.
What mainstream browsers aren't defaulting to utf-8 in 2025?
html5 does not even allow any other values in . I think you need to use a different doctype to get what the screenshot shows.
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).
Earlier quoted context omitted.
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 :(
> s/lange/lang/ > 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 misbehaves (parsing as 1 instead of 1½) with LC_NUMERIC=fr_FR.UTF-8 on any user age…
Wow. This reminds me of Google Sheets formulas, where function parameters are separated with , or ; depending on locale.
I know this was a joke: but I feel there is a last tag missing: ... that will ensure screenreaders skip all your page "chrome" and make life much easier for a lot of folks. As a bonus mark any navigation elements inside main using (or role="navigation").
Earlier quoted context omitted.
Wow. This reminds me of Google Sheets formulas, where function parameters are separated with , or ; depending on locale.
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 ';'.
I know this was a joke: but I feel there is a last tag missing: ... that will ensure screenreaders skip all your page "chrome" and make life much easier for a lot of folks. As a bonus mark any navigation elements inside main using (or role="navigation").
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).
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?
This should be fixed, though.
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…
At quick glance, it looks like they're still using the same CSS that was made public ~13 years ago:
https://github.com/wting/hackernews/blob/5a3296417d23d1ecc90...
Earlier quoted context omitted.
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.
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.