The number of reference pixels reported to JS changes but so does window.devicePixelRatio. In JS this info is given for you to do your own logic with, in CSS it is not. As such it's not "scaled up at the last step" any more than at 100% zoom when CSS finds out that means foo inches at bar zoom is foobar physical px on a certain monitor. This is opposed to MacOS/iOS or Gnome where things are calculated against a reference scale and then that reference is scaled an integer amount and then that rendered bitmap is scaled by the dpi factor to be displayed - in CSS layout dimensions are always just passed to be directly rendered to the display and part of that direct pass is it always has to figure out how many device px the reference px is.
Not to preserve user choice in itself no but em isn't preserving user choice in the end either so it's not an argument to convince either side.
It's a problem in the same way your original example was a problem i.e. there is no way to reconcile all of these with good answers consistently so that a certain layout methodology doesn't is proof of nothing. And all options being imperfect leads to the simpler dimension based layout being popular. Of course that means a relative dimension based layout is no more inherently "wrong" just most find it harder to work with and get nothing new they couldn't have accomplished with any other dimension type + the describing CSS syntax.
Percentage/viewport based layouts independently may be an actual "wrong" choice depending what kind of content the page contains. The CSS spec actually reflects that percentage based layout is a unique design choice - em and px are both a "dimension" type and you can make either do the same thing with CSS if you wanted (that doesn't mean just replace em with px and call it a day but it's always doable) whereas percentage and viewport are their own special "percentage" type and you can't make them always behave like another unit type because they actually represent a unique concept.
At least once or twice a day I’ll find a comment on HN that just 100% completely humbles me. This is that comment. Where do you learn things like this?
Ironically I don't consider myself all that knowledgable at this kind of stuff for the most part - this just happens to be a very particular thing I went deep down the rabbit hole on in a passion project where I was trying to find out how to solve this exact "how should layouts render on different displays" problem. Turns out the web browser's approach to the problem is very elegant even if the specifications have a lot of complexity and warts from organic growth so I spent a lot of time looking at the specs to make sure I understood how I wanted to do my own thing.
In short do fun things you just want to understand and you too can sound much smarter than you are when a certain topic comes up :).
> As such it's not "scaled up at the last step" any more than at 100% zoom when CSS finds out that means foo inches at bar zoom is foobar physical px on a certain monitor.
Technically yes, but practically no. If you zoom in on a screen, CSS breakpoints based on resolution will trigger. As far as your actual CSS styling goes, you can basically think of the page as having a smaller resolution that then gets scaled up after layout is determined. CSS doesn't have access to the information you're talking about, so it's not valuable to a designer to think in those terms -- at least not unless you're planning to embed a bunch of interface logic in Javascript that doesn't belong there.
The end result is that if you zoom in 200% on an 800px wide viewport, from the perspective of the CSS you're writing you are effectively working with a 400px wide viewport.
> but em isn't preserving user choice in the end either so it's not an argument to convince either side.
This continues to be a compelling argument.
What I will say though is that the more I reflect on it, the more this seems to be an argument for using both `px` and `em` units based on the context of the individual component you are styling. It doesn't seem to be an argument for abandoning relative/point units entirely, as the original article advocates. From the perspective that scaling text alongside containers and scaling text inside containers are both valid ways to scale content, there are going to be some parts of your interface where it makes sense to respond to text size increasing, and some parts that don't.
So for example, I can buy that for a main paragraph, you might want users to have the ability to scale text independently of the column width. But while you're doing that, you probably still want labels to fit inside of buttons. Similarly, you probably don't want the text options on a dropdown menu to overlap with each other and make each other unclickable. And more typographically, you want margins between your paragraphs to remain readable.
So maybe in that scenario if you're maximizing user choice it makes sense to leave you main column in pixels and to only set menus, buttons, and paragraph spacing and margins in `em` units. I could see something like that being reasonable.
The ending of your comment confuses me. I've never heard someone say that percentage-based layouts are explicitly the "wrong" choice, sometimes it does make sense to have a 2-column 50% layout. More specifically:
> `em` and `px` are both a "dimension" type and you can make either do the same thing with CSS if you wanted (that doesn't mean just replace em with px and call it a day but it's always doable)
`em` is a relative size based on the current container's font. So a `4em` sized box means `4 * container_font_size_in_pixels`. There's no way to represent that logic with pixels unless you're using Javascript to change the CSS whenever the font changes. Because `em` units aren't a constant logical unit, they're dependent on the context of the container they're set on.
But if you're going to be updating your layout with Javascript all the time, then you can also absolutely use percentages to get the same layout as pixels as well, they're not a fundamentally different measurement in that scenario. You can have a 1000px container and set all of its children to use percentages, and do all the math to make them line up. You can have Javascript that catches page resizes and readjusts all of its styles.
But if we're talking about the underlying logic, both `em` and percentage units are defined in relation to another unit. They're not equivalent to a fixed value, they scale depending on where they are in the DOM and what those other units are currently doing.
If you're working in pure CSS, there are components you can build that will have behaviors that are impossible to replicate with pixels. If you build a dropdown menu that's using `em` units, it will act differently depending on where it's inserted into the DOM. Pixels won't.
> What I will say though is that the more I reflect on it, the more this seems to be an argument for using both `px` and `em` units based on the context of the individual component you are styling. It doesn't seem to be an argument for abandoning relative/point units entirely, as the original article advocates. From the perspective that scaling text alongside containers and scaling text inside containers are both valid ways to scale content, there are going to be some parts of your interface where it makes sense to respond to text size increasing, and some parts that don't.
Yeah I'd agree with this as well after all of the thought on it - if you want to really get to the full 100% mixing the units per part of the design as you describe is going to enable a more optimized outcome than any "pure" approach could get to.
The way to make px behave like em in pure CSS is to set dimensions based on a --custom-property so you can do things like width: calc(var(--parents-font-size * 2.5)) or what have you. Bit messier if all you literally want to do is font sized based scaling but also way more flexible to inject other logic into if you want to do more than that. Of course JS can give you even more freedom to change these kinds of things (no restrictions that types have to match and such) but that comes with it's own swath of problems not needed for most anything that isn't a true app-in-a-page.
Not to preserve user choice in itself no but em isn't preserving user choice in the end either so it's not an argument to convince either side.
It's a problem in the same way your original example was a problem i.e. there is no way to reconcile all of these with good answers consistently so that a certain layout methodology doesn't is proof of nothing. And all options being imperfect leads to the simpler dimension based layout being popular. Of course that means a relative dimension based layout is no more inherently "wrong" just most find it harder to work with and get nothing new they couldn't have accomplished with any other dimension type + the describing CSS syntax.
Percentage/viewport based layouts independently may be an actual "wrong" choice depending what kind of content the page contains. The CSS spec actually reflects that percentage based layout is a unique design choice - em and px are both a "dimension" type and you can make either do the same thing with CSS if you wanted (that doesn't mean just replace em with px and call it a day but it's always doable) whereas percentage and viewport are their own special "percentage" type and you can't make them always behave like another unit type because they actually represent a unique concept.