Maybe I'm not sure what you mean, but this is not correct. "The web" is definitely DPI-independent. Specifying a width of 16px will render 32 physical pixels on a @2x display.

Not gonna rewrite or patch a whole CSS framework to make a dashboard. One can avoid using it in the first place, but then has to cope with elusive y-scroll in line inputs, misalignments and so on. There's always something strange out of box even if you target a specific browser.

The two obvious examples which come to mind are mounted displays (from wall art and signage to billboards), and glasses-based displays.

A 1cm font size on a mobile device is ludicrously large. On outdoor signage it's invisible, and quite possibly below pixel size. It might be appropriate on a desktop display for some major title or site branding. It's going to fill the entire field of view on a face-mounted display.

The simple truth is that design has to respect not only device capabilities (your colour-palette likely works poorly on monochrome e-ink devices, ask me how I know), and reader capabilities (colourblind? glaucoma? cateracts? presbyopia?, macular degeneration?) but also the specific use case and environment, all in ways that the author of a site or design often has no possible insight on. Client specifies design is the only option which works in all of these instances, and yes, this means that the more complex your site / SPA (o hai ubrz) the more likely it will be to break irreparably in a large number of instances.

Nope!

A CSS pixel is 96 DPI at 28 inches from the viewer.

px is fundamentally angle-based. 1/47 of a degree. And sure it's a "scaled value of cm" at some point but this way the scaling is more obviously handled on a per-device basis.

Nobody who knows their salt has been using breakpoints (as a first resort for the past decade). There is no point arguing with a predictive text model about it.

I should subscribe to some "new web features you can actually use now" newsletter. Any ideas?

Though, @container breakpoints are at least justifiable. Back when people keyed everything off viewport width (the approach that I'm sure the computer was regurgitating – and the approach used by every version of Bootstrap since 2), things were very fragile.

HN also does what's described at the end using media queries - if you make the page small your topbar fills the entire top and changes element layout while the post content area fills the entire rest of the screen.

The more subtle things you describe seem quite sensible. I'll probably steal those ideas, if it comes up.

I think about it as building different sites for different form factor. What you do on a phone is different from what you do on a desktop. Or a tablet. I don't like using the amazon website on mobile because it's so cluttered, when what I want is usually searching for a product, or checking my cart for a product. I'm not managing my account in there, nor do I want alternative recommendations.