3 ms·

> Font size strongly relates the sizing of all your other interface elements, which are naturally defined in logical pixels (or "px"). You can't design your way

> Font size strongly relates the sizing of all your other interface elements, which are naturally defined in logical pixels (or "px"). You can't design your way around that. A huge part of responsive design is the art of designing your way around that. In most cases (not all, but most), don't define your interface elements in pixels (or any other logical unit that is unrelated to font size). I also see native apps fail at this, but it's not because it's an unsolveable problem, it's because a lot of native apps are behind the times on responsive design. Normally I'd criticize native UI toolkits here as well, but the truth is that for many toolkits (including GTK and QT) this hasn't been a problem for a while; most popular UI toolkits support font-based widths for layout. Designers just have to take advantage of those features.

incrudible 6y ago
The operating system sizes everything according to the equivalent of devicePixelRatio, not font size. Device manufacturers choose this value according to screen size and pixel density. It is reasonably predictable. The em-size however could be anything. If your intent is to drive the layout with font size, using units such as "em" does the exact opposite of what you want: you're simply adding another unpredictable factor into your size calculations. > A huge part of responsive design is the art of designing your way around that. Using "px" for responsive design works just fine. What exactly is the advantage of "em" in this regard?
- danShumway 6y ago
  > 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.
  - incrudible 6y ago
    > 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.
    - danShumway 6y ago
      > 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.

incrudible 6y ago

The operating system sizes everything according to the equivalent of devicePixelRatio, not font size. Device manufacturers choose this value according to screen size and pixel density. It is reasonably predictable. The em-size however could be anything. If your intent is to drive the layout with font size, using units such as "em" does the exact opposite of what you want: you're simply adding another unpredictable factor into your size calculations. > A huge part of responsive design is the art of designing your way around that. Using "px" for responsive design works just fine. What exactly is the advantage of "em" in this regard?

danShumway 6y ago
> 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.
- incrudible 6y ago
  > 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.
  - danShumway 6y ago
    > 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.