Tags to make HTML work like you expect (opens in new tab)

Modern design trends are going backwards. Tons of spacing around everything, super low information density, designed for touch first (i.e. giant hit-targets), and tons of other things that were considered bad practice just ten years ago.

So HN has its quirks, but I'd take what it is over what most 20-something designers would turn it into. See old.reddit Vs. new.reddit or even their app.

To test, try setting your browser's font size larger or smaller and note which websites update and which do not. And besides helping to support different user preferences, it's very useful for accessibility.

[1] After testing, it looks like the "Reply" and "Help" links respect large browser font sizes.

None of the ”content needs white space and large fonts to breathe“ stuff or having to click to see a reply like on other sites. That just complicates interactions.

And I am posting this on an iPhone SE while my sight has started to degrade from age.

https://userstyles.world/style/9931/

On what devices (or browsers?) it renders "insanely small" for you? CSS pixels are not physical pixels, they're scaled to 1/96th of an inch on desktop computers, for smartphones etc. scaling takes into account the shorter typical distance between your eyes and the screen (to make the angular size roughly the same), so one CSS pixel can span multiple physical pixels on a high-PPI display. Font size specified in px should look the same on various devices. HN font size feels the same for me on my 32" 4k display (137 PPI), my 24" display with 94 PPI, and on my smartphone (416 PPI).

It has been changed since then for sure though. A couple of years ago the mobile experience was way worse than what it is today, so something has clearly changed. I think also some infamous "non-wrapping inline code" bug in the CSS was fixed, but can't remember if that was months, years or decades ago.

On another note, they're very receptive to emails, and if you have specific things you want fixed, and maybe even ideas on how to do in a good and proper way, you can email them (hn@ycombinator.com) and they'll respond relatively fast, either with a "thanks, good idea" or "probably not, here's why". That has been my experience at least.

On mobile it’s fine, on Mac with a Retina display it’s fine; the only one where it isn’t is a 4K display rendering at native resolution - for that, I have my browser set to 110% zoom, which is perfect for me.

So I have a workaround that’s trivial, but I can see the benefit of not needing to do that.

There is no such thing as a reasonable default size if we stop calibrating to physical dimensions. If you choose to use your phone at a scaling where what is supposed to be 1" is 0.75" then that's on you, not on the website to up the font size for everyone.

There's a trend to make fonts bigger but I never understood why. Do people really have trouble reading it?

I prefer seeing more information at the same time, when I used Discord (on PC), I even switched to IRC mode and made the font smaller so that more text would fit.

It's also more complex to do JS builds in Ruby when Ruby isn't up to the task of doing builds performantly and the only good option is calling out to other binaries. That can also be viewed from the outside as "we painted ourselves into a corner, and now we will discuss the virtues of standing in corners". Compared to Bun, this feels like a dated perspective.

DHH has had a lot of opinions, he's not wrong on many things but he's also not universally right for all scenarios either and the world moved past him back in like 2010.

I'm old enough to have a first hand experience of building a Flash website that required to load couple hundred tiny xml files for configuration only to find out that some ~300kb was taking couple of minutes to load because of limited connection pool in old http.

Back then bundling and overly complicated build steps were not yet invented, so instead of serving one large XML (which would work out of the box, as there was a root xml and certain nodes instead of having data were linking to external files) I quickly decided to implement zip compression and bundle the package that way.

Fast forward to 2025 when most devs need an external library to check if number isEven and the simplest project need a toolchain that's more complicated that the whole Apollo project.

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

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

Who would want to use a browser which would prevent many currently valid pages from being shown?

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.

I get not having read all the way to the end and back, I even get having margins, but it should be relative to the screen size. Fixed width is the issue I think. To avoid paragraphs looking too thin, maybe increasing the font relative to the screen size makes sense? I'd think there is a way to specify a reference screen resolution to the browser so that it can auto increase the font sizes and/or adjust the div's width.

This wouldn't be the first thing I'm just weird about. Similarly, I find reading justified text to be just horrible, as I constantly lose track of what line I'm on. This one I believe has been debunked and raised as a genuine accessibility concern, but not all parts of the world have gotten around to recognising that. I'm also not a fan of serifed fonts, even in books. I'm not sure if there have been any studies made about that, as the serifs are supposed to be there to aid reading when printed on paper, but I consistently find a good sans-serif font to be better in all cases.

If Wikipedia had 70 characters per line I would never read it.

You would think browsers themselves would handle the rest, if the website simply specified "center the content div with 60% width" or something like that.

Navigation should come early in document and tab order. Screen readers have shortcuts for quickly jumping around the page and skipping things. It's a normal part of the user experience. Some screen readers and settings de-prioritize navigation elements in favor of reading headings quickly, so if you don't hear the navigation right away, it's not necessarily a bug, and there's a shortcut to get to it. The most important thing to test is whether the screen reader says what you expect it to for dynamic and complex components, such as buttons and forms, e.g. does it communicate progress, errors, and success? It's usually pretty easy to implement, but this is where many apps mess up.

I remember HTML has an way to create global shortcuts inside a page, so you press a key combination and the cursor moves directly to a pre-defined place. If I remember that right, it's recommended to add some of those pointing to the menu, the main content, and whatever other relevant area you have.

This is now "standard" but breaks any browser that doesn't (or can't) support javascript. It's also a nightmare for SEO, accessibility and many other things (like your memory, cpu and battery usage).

But hey, it's "modern"!

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

[0] https://en.wikipedia.org/wiki/Decimal_separator#Conventions_...

Windows distributes ISOs labelled English (en-US) and English International (en-GB) along this divide.

It’s also a valuable divide for reasons beyond language, because the USA really does have a habit of doing its own thing, even when pretty much the rest of the world has agreed on something different. Your US English locale can default to Fahrenheit, miles, pounds, Letter, and their bizarre middle-endian date format, while International English can default to Celsius, kilometres, kilograms, A4, and DD/MM/YYYY. It doesn’t sort out everything, but it gives a much better starting point. Not every non-American prefers DD/MM/YYYY, but even if they’d prefer something like DD.MM.YY or YYYY-MM-DD, DD/MM/YYYY is a whole lot better than MM/DD/YYYY.

A dedicated one for International English, or heck, even just EU-English, would be great.

The EU websites just use en from what I can tell, but they also just use de, fr, sv, rather than specifying country (except pt-PT, which makes sense, since pt-BR is very common, but not relevant for the EU).

I had a teacher who became angry when a question was asked about a subject he felt students should already be knowledgeable about. "YOU ARE IN xTH GRADE AND STILL DON'T KNOW THIS?!" (intentional shouting uppercase). The fact that you learned it yesterday doesn't mean all humans in the world also learned it yesterday. Ask questions, always. Explain, always.

[0] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...

This should be fixed, though.

But again there's mixed language issue

Or do users even bother to choose the correct lang?

1) Pronounciation is either solved by a) automatic language detection, or b) doesn't matter. If I am reading a book, and I see text in a language I recognize, I will pronounce it correctly, just like the screen reader will. If I see text in a language I don't recognize, I won't pronounce it correctly, and neither will the screen reader. There's no benefit to my screen reader pronouncing Hungarian correctly to me, a person who doesn't speak Hungarian. On the off chance that the screen reader gets it wrong, even though I do speak Hungarian, I can certainly tell that I'm hearing english-pronounced hungarian. But there's no reason that the screen reader will get it wrong, because "Mit csináljunk, hogy boldogok legyünk?" isn't ambiguous. It's just simply Hungarian, and if I have a Hungarian screen reader installed, it's trivial to figure that out.

2) Again, if you can translate it, you already know what language it is in. If you don't know what language it is in, then you can't read it from a book, either.

3) See above. Locale is mildly useful, but the example linked in the article was strictly language, and spell checking will either a) fail, in the case of en-US/en-UK, or b) be obvious, in the case of 1) above.

The lang attribute adds nothing to the process.