> The operating system sizes everything according to the equivalent of devicePixelRatio, not font size.
You just finished telling me that "font size strongly relates the sizing of all your other interface elements". And I agree with that, which is why it's preferable to use a unit that's tied to font size.
> The em-size however could be anything.
The `em` size is a constant based on the current font and font scale that the user/OS has selected that will scale predictably as that specific font scales.
> What exactly is the advantage of "em" in this regard?
It scales predictably alongside the currently displayed font. It almost completely solves the problem of Mac and Windows displaying fonts at different sizes. Again, you just finished telling me that handling OS font-size differences was a task that I was guaranteed to mess up. Well, `em` and `rem` units make it so you won't mess that up.
When a user changes their fonts to be 1.5x as large, you don't want to be using a logical unit for your layouts and popup window widths that completely ignores that change.
> You just finished telling me that "font size strongly relates the sizing of all your other interface elements". And I agree with that, which is why it's preferable to use a unit that's tied to font size.
It is not preferable, because em-size is decoupled from the size of other UI elements.
> The `em` size is a constant based on the current font and font scale that the user/OS has selected that will scale predictably as that specific font scales.
Anything in this chain could change em-size: The OS, the OS setting, the UI toolkit, the browser, the browser setting - independently of the rest of the UI elements. Those changes could have been made by the OS vendor, the device vendor, the browser vendor or the user. That's what makes it unpredictable and that's why it breaks.
> Again, you just finished telling me that handling OS font-size differences was a task that I was guaranteed to mess up. Well, `em` and `rem` units make it so you won't mess that up.
They don't. You probably just don't know you messed it up, because you haven't tested all the devices out there.
> When a user changes their fonts to be 1.5x as large, you don't want to be using a logical unit for your layouts and popup window widths that completely ignores that change.
Here's how you actually achieve that: Use "px" everywhere. The only reason I see for using "em" in place of "px" is that you want to decouple the scaling of fonts/labels from the overall scaling of the UI. However, you probably shouldn't want that, because it's going to mess things up.
> It is not preferable, because em-size is decoupled from the size of other UI elements.
Only if you make it that way.
You're arguing that I should size my layout in pixels because... I size it in pixels? If your em-size is decoupled from the size of your other UI elements, that's a choice you made, it's not the OS forcing you to do that. We're talking about the decision not to decouple em-size from the size of other UI elements. There are tons of popular, modern desktop UI toolkits that give you the ability to do that.
> Anything in this chain could change em-size: The OS, the OS setting, the UI toolkit, the browser, the browser setting - independently of the rest of the UI elements
No, any of those things could change the base em size of the font. Which will then scale linearly and predictably as long as you're using `em` and `rem` units everywhere, including for your layout.
> Here's how you actually achieve that: Use "px" everywhere.
You're commenting this underneath an article that explicitly complains that the pixel approach doesn't work today because OSes define fonts in points, because users can override your choices for font sizes, and because these units are not a uniform size across different operating systems.
Meanwhile, if you build a QT app and use `em` units, it just works.
And of course it works, because regardless of whether or not you think that pixels would be great for fonts, users still get to override your font choices on native devices. The only way to solve that problem is to tie width to font size. You're complaining that anything can change the base `em` value of a piece of text, and I'm sorry to tell you this but on most modern UI Toolkits users can also change the font and size of your text content even if you set it in pixels.
Unless you're advocating that Gnome/iOS/Android/Mac should get rid of their current text scaling accessibility options, which... good luck. Pixels won't save you from that stuff, container widths based on current font size will, because for very good reasons you increasingly don't get the option on modern computers to force font to be a specific size.
> is that you want to decouple the scaling of fonts/labels from the overall scaling of the UI
I worry we're talking past each other. Don't decouple anything. Use `em` units to scale how large a container, button, margin, image should be. Use them everywhere, not just on your fonts.
If you just use "em" scale for everything, you simply add another factor into the size calculation. It's the same as just using "px" directly, except it's now also larger/smaller depending on the font-scale, on top of the UI scale. Most of the time, on most devices, you won't notice that, but on some devices it will make everything unexpectedly larger or smaller, usually due to some vendor setting not matching well with devicePixelRatio.
> You're commenting this underneath an article that explicitly complains that the pixel approach doesn't work today because OSes define fonts in points, because users can override your choices for font sizes, and because these units are not a uniform size across different operating systems.
If you specify font size in "px" (instead of "pt"), font size will roughly match pixels/devicePixelRatio, which is as consistent as it gets across platforms. Using "em" instead would be less consistent.
> Unless you're advocating that Gnome/iOS/Android/Mac should get rid of their current text scaling accessibility options, which... good luck. Pixels won't save you from that stuff, container widths based on current font size will, because for very good reasons you increasingly don't get the option on modern computers to force font to be a specific size.
The intended behavior of changing the font size is to not scale the whole UI, just the fonts. If you use "em" for everything, you just defeat that feature. You might as well use "px" directly, it's more predictable and easier to think about.
You just finished telling me that "font size strongly relates the sizing of all your other interface elements". And I agree with that, which is why it's preferable to use a unit that's tied to font size.
> The em-size however could be anything.
The `em` size is a constant based on the current font and font scale that the user/OS has selected that will scale predictably as that specific font scales.
> What exactly is the advantage of "em" in this regard?
It scales predictably alongside the currently displayed font. It almost completely solves the problem of Mac and Windows displaying fonts at different sizes. Again, you just finished telling me that handling OS font-size differences was a task that I was guaranteed to mess up. Well, `em` and `rem` units make it so you won't mess that up.
When a user changes their fonts to be 1.5x as large, you don't want to be using a logical unit for your layouts and popup window widths that completely ignores that change.