5 ms·

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

by wruza 2y ago

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 2y ago
> 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 2y ago
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.
- wruza 2y ago
  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 2y ago
    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.
- dredmorbius 2y ago
  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.
- Dylan16807 2y ago
  > 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.
wizzwizz4 2y ago
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 2y ago
  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.
  - wizzwizz4 2y ago
    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 2y ago
      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.
thr33 2y ago
expecting to use cm/in for digital design is ludicrous.

by wruza 2y ago

madeofpalk 2y ago

> 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 2y ago

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.

wruza 2y ago
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 2y ago
  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.
dredmorbius 2y ago
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.
Dylan16807 2y ago
> 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.

wizzwizz4 2y ago

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 2y ago
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.
- wizzwizz4 2y ago
  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 2y ago
    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.

thr33 2y ago

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