4 ms·

> Again by definition "zoom text only" is meant to change the proportions of the design Not necessarily. Zoom text only is meant to change the font size and by

> Again by definition "zoom text only" is meant to change the proportions of the design Not necessarily. Zoom text only is meant to change the font size and by extension things that are based off of the font size. Full-page zoom pretends that the browser window is a different resolution (even reporting a different resolution to Javascript) and then scales the page up in the final rendering step. I don't know that the point is necessarily to preserve/change proportions one way or another, they're different algorithms that affect different parts of the page. This is still a really, really interesting perspective, arguably the most interesting/compelling justification that I've heard on this entire thread as to why a designer might choose to use pixels for width in a normal layout. But even though you have an interesting and insightful take, I'm not sure I buy that the reason designers are ignoring `em` units is to preserve user choice. And in practice in the real world, I notice that the pages that follow an `em`/`rem` philosophy when thinking about column width tend to handle both resizing of text and full-page zoom better. Let me ask a question; if the goal of full-page zoom is actually to keep the same proportions for its font-size, if that's really the main difference between font-only zoom and full-page zoom, then is it a problem that full-page zoom doesn't affect percentages or viewport width units? Why draw the line specifically at the ratio of font-size to container width? If the point of full-page zoom is to preserve proportions and ratios, shouldn't it act more like zooming a PDF?

zamadatix 6y ago
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.
- austinkhale 6y ago
  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?
  - zamadatix 6y ago
    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 :).
- danShumway 6y ago
  > 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.

zamadatix 6y ago

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.

austinkhale 6y ago
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?
- zamadatix 6y ago
  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 :).
danShumway 6y ago
> 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.