[wruza]

I remember having a heated discussion with an LLM about this. For some reason "web" doesn't even consider to respect dpi and angular sizes and instead relies on "breakpoints", which "is important to remember to test on all sorts of devices".

That's just bs. As a maker of UI, I want to get a rectangle, put my controls on it with the sizes in cm/in/° as I see fit and then to just slide right-bottom to see what happens on different screen sizes. One doesn't have to buy a foot-high stack of smartphones and tablets to test an effing label.

The whole issue stems from the fact we can't measure things correctly, cause the whole measurement system bases on ideas from winword era.

[madeofpalk]

> For some reason "web" doesn't even consider to respect dpi and angular sizes

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.

[zamadatix]

What's stopping you from using cm/in as your unit (which is actually also what px is based off of in the web, not physical pixels)? ° doesn't make sense until you pick a viewing distance, at which point you're really back to some scaled value of cm/in.

[dredmorbius]

Fixed size layout runs into problems where you're working with displays that aren't at typical desktop / laptop / mobile distances from the retina.

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.

[wruza]

What's stopping you from using cm/in as your unit

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.

[zamadatix]

Which CSS framework out of curiosity? I don't know many that won't let you use px, which is 1/96th an inch at any DPI, and if it really doesn't let you use the most basic sizing element on the web then the problem seems more with the chosen framework than anything to do with browsers :p.

[Dylan16807]

> cm/in as your unit (which is actually also what px is based off of in the web, not physical pixels)? ° doesn't make sense until

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.

[thr33]

expecting to use cm/in for digital design is ludicrous.

[wizzwizz4]

Endlessly-replagiarised blog posts about Bootstrap and friends will talk about breakpoints as though they're the greatest thing since the printing press. Outside the hypey framework world, they were only ever in vogue for long enough for us to realise that they didn't really work that well. By that time, we had flexbox, and grid followed shortly after.

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.

[zamadatix]

The blog post design/airbnb site are pretty reliant on @container breakpoints. Even with flex/grid layouts you usually want to change things up significantly when it gets down to single column.

[dvdkon]

I just found out container queries are widely available, nice!

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

[wizzwizz4]

Why? Reading order is page order, so it should just work.

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.

[zamadatix]

It's easier to see if you play with it on the actual site rather than look at the images and try to deduce what could be different. It's not really related to things like order or positioning of boxes, that's an extremely easy problem to solve. Some of it is loading progressively space saving assets e.g. the logo goes from "${icon} airbnb" to "${icon}" to "" depending on how much space there is, the search bar simplifies so you have space to actually type, and some content border elements are removed so there is more room for the actual content e.g. rather than blindly always show content boxes with rounded borders, spacing, and other attributes you can gain a lot of space back on small displays by stretching the container's content to fill that part of the screen completely. This is particularly useful if you combine this with getting rid of certain UI elements from earlier.

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.

[wizzwizz4]

And if you make your page slightly bigger than the threshold for triggering HN's "mobile view", there's still padding in the top bar but the page is 53 pixels too wide, and you have to scroll horizontally. Hacker News is an example of why we don't use media queries to hack in a responsive layout. Websites are responsive by default, unless you're using <table> layouts (as HN does) or the <div>pocalypse (as every other website seems to, these days). Building different versions of your site for different widths is not a solution.

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

[skydhash]

> Building different versions of your site for different widths is not a solution.

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.

[zamadatix]

Yeah, you can definitely fuck it up, but the same can be said for flex/grid/masonry layouts yet you wouldn't say "and grid spanning errors on resize are why we never use grid". HN does a lot "wrong" in its design (like the aforementioned table hell) but that doesn't mean every mistake it makes is a universal thing to avoid and inherent to the way it was implemented. Reddit, YouTube, Facebook, Instagram, Netflix, X, Amazon, and most modern sites do the same kind of content box snapping on either the header or content area (or both) via breakpoints. Most do it a lot better than HN :). The top site I know that doesn't really do that (but it does do the minor breakpoint things) is Yahoo.com.