6 ms·

> which is the difference, and only difference, vs using rem or pt or px or pc or any other absolute sizing reference It's a difference for anyone who changes

> which is the difference, and only difference, vs using rem or pt or px or pc or any other absolute sizing reference It's a difference for anyone who changes the default text size in Firefox. The "Zoom Text Only" option works the same way as Firefox's default text sizing. This is a difference that does matter for anyone who adjusts either the default or minimum font size in their browser, it's not theoretical. > I like defining the root font size in px and using rem everywhere else This is better than using pixels everywhere. I would not define a root font size in pixels, I would leave it as 1rem. BUT, what you're doing is much, much better than what the article is proposing, so I'm not going to be too critical.

zamadatix 6y ago
Again by definition "zoom text only" is meant to change the proportions of the design, that the proportions of the design were changed accordingly is not proof the design method is wrong it's proof only text was zoomed. If you use em for everything as a "fix" for this you've actually just broken the whole point of "zoom text only" as it just became functionally identical to "zoom". I.e. there is no way to reconcile "zoom text only" not changing the proportions of the design and having a meaningful "zoom text only" at the same time. That something can't do both is therefore proof of nothing. The same as above is true for the root font size discussion, if you set it relative and base the page layout on relative than the user's default font size setting also just turns into a proxy for a full page zoom. Again it's not proof in itself that one is right or wrong it's just that you're either going to stomp on the users default font preference by making it zoom everything instead or you're going to have a design that looks wonky for users with high custom font sizes because the layout wasn't made for big text.
- danShumway 6y ago
  > 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 :).
girvo 6y ago
I’ve not checked: I change the default text size on my iPhone. Does that impact Safari?
- danShumway 6y ago
  I don't use Safari/iOS, so I don't know for certain, but AFAIK the answer is no. However, I believe in the most recent version of iOS Safari there will be an option in the left-hand corner of the URL to adjust text size for any page you're on, and Safari will remember that setting on a per-domain basis. But again, I don't own an iOS device, so I'm not sure exactly what algorithm it uses to resize. It says it's text resizing, but maybe behind the scenes it's doing something different.
elpince 6y ago
I think you are missing the main point : default text size IS a size in pixel. If my memory serves me right, the default text size is 16px for chrome (not sure about other browsers). Be it rem, em they are sizes relative to an ancestor. rem being the root ancestor (html selector or browser default), and em being the closest ancestor having an absolute value defined for its font-size property. Em is great when you want to establish a font size hierarchy in some container for example. You can test rem by setting media queries defining different font-size values. You'll see that 1.75rem is always exactly 175% of root element's font-size value.
- danShumway 6y ago
  That is a point, but it's not a point that matters. It's no different then saying "oh, but browser pixels eventually resolve down to physical screen pixels, so it's the same thing." The problem here isn't whether or not font size eventually at some point in the browser is getting set to pixels -- it's who sets it. Is the browser setting it? Is the user? And is your layout equipped to handle it when it changes?

zamadatix 6y ago

Again by definition "zoom text only" is meant to change the proportions of the design, that the proportions of the design were changed accordingly is not proof the design method is wrong it's proof only text was zoomed. If you use em for everything as a "fix" for this you've actually just broken the whole point of "zoom text only" as it just became functionally identical to "zoom". I.e. there is no way to reconcile "zoom text only" not changing the proportions of the design and having a meaningful "zoom text only" at the same time. That something can't do both is therefore proof of nothing. The same as above is true for the root font size discussion, if you set it relative and base the page layout on relative than the user's default font size setting also just turns into a proxy for a full page zoom. Again it's not proof in itself that one is right or wrong it's just that you're either going to stomp on the users default font preference by making it zoom everything instead or you're going to have a design that looks wonky for users with high custom font sizes because the layout wasn't made for big text.

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

girvo 6y ago

I’ve not checked: I change the default text size on my iPhone. Does that impact Safari?

danShumway 6y ago
I don't use Safari/iOS, so I don't know for certain, but AFAIK the answer is no. However, I believe in the most recent version of iOS Safari there will be an option in the left-hand corner of the URL to adjust text size for any page you're on, and Safari will remember that setting on a per-domain basis. But again, I don't own an iOS device, so I'm not sure exactly what algorithm it uses to resize. It says it's text resizing, but maybe behind the scenes it's doing something different.

elpince 6y ago

I think you are missing the main point : default text size IS a size in pixel. If my memory serves me right, the default text size is 16px for chrome (not sure about other browsers). Be it rem, em they are sizes relative to an ancestor. rem being the root ancestor (html selector or browser default), and em being the closest ancestor having an absolute value defined for its font-size property. Em is great when you want to establish a font size hierarchy in some container for example. You can test rem by setting media queries defining different font-size values. You'll see that 1.75rem is always exactly 175% of root element's font-size value.

danShumway 6y ago
That is a point, but it's not a point that matters. It's no different then saying "oh, but browser pixels eventually resolve down to physical screen pixels, so it's the same thing." The problem here isn't whether or not font size eventually at some point in the browser is getting set to pixels -- it's who sets it. Is the browser setting it? Is the user? And is your layout equipped to handle it when it changes?