Hacker News Reader

> because "em" are still defined in terms of "px" at the root element

No they're not, they're tied to the resolved font size of the current element they're in.

That matters if someone overrides part of the CSS, so even from a pure engineering perspective this makes a real difference. It also matters if the user changes the font size of their browser.

`em` units define font size in relation to the current font size. That font size might be set elsewhere in CSS using pixels, it might be set by the browser. It might be set using viewport width, it might be set using percentages. It might be set in pixels and overridden by the user using the browser's minimum font size feature.

In all of those cases, as a designer you will be glad that you used `em` units for container width and child text rather than pixels.

> Nobody does that anymore. That was how browsers zoomed two decades ago.

This is how Firefox's default font sizing works today. I listed that zoom option so it would be easier for you to play with it, that's the only reason. But if you go into your settings and change the default font size of the browser (which is absolutely something that people who have bad vision still do today), then you will see the same result in the JSFiddle I linked.

> This is how Firefox's default font sizing works.

That's misleading. Firefox's default zoom sizing zooms fonts together with everything else. Virtually nobody uses font-only zooming. People with bad vision still overwhelmingly use page zoom -- because if your vision is bad you need everything enlarged, including things like icons and images.

Also, your description of how font size for em's is set is incorrect. It's always set ultimately relative to px. If set by the browser, it's a default stylesheet that specifies "body { font-size: 16px; }". It cannot be set as a percentage of viewport size using HTML/CSS, that doesn't exist as an option in font-size. If the browser sets a minimum font size, that too is ultimately in px.

Your whole argument hinges on people using font-zooming, when that died for all intents and purposes many, many years ago. There's no reason for web designers to accomodate nonstandard font zoom anymore -- forcing all UX units to be in ems just re-implements page zoom using text zoom, which is utterly redundant.

Use px or use rem, they're functionally equivalent -- it's just a matter of developer preference.

> Virtually nobody uses font-only zooming.

I don't know how you can claim this. I have set up multiple computers for elderly people and taken advantage of that feature. Heck, I have taken advantage of that feature on devices with weird aspect ratios like the older Surface Pros.

> It cannot be set as a percentage of viewport size using HTML/CSS, that doesn't exist as an option in font-size

What?

  font-size: 1vw;

> If the browser sets a minimum font size, that too is ultimately in px.

This is being pedantic. If a user or a parent container is setting the font size, that is clearly a different scenario then setting it in the container itself.

If you're going to go down this route we might as well claim that browser fonts are set based on physical pixels as well, since ultimately the browser resizes its internal representation of pixels based on the device aspect ratio.

> it's just a matter of developer preference.

I don't know any experienced developer who writes CSS for a living that would claim this. Pixel-based CSS files are a nightmare to maintain when nesting components, this makes a tangible difference to how you architecture your CSS files.

Wow, you're right about vw. I've never once seen it in the wild, MDN's page for font-size certainly doesn't mention it, and I've never seen it listed anywhere as a best practice. But TIL, thanks.

It's clear you really like font-zoom, and also that your preference is extremely uncommon. I still don't know why you recommend writing CSS using "em" dimensions for UI elements to work with font-zoom, rather than just "px" with page zoom, when the end result is identical. I mean... why would you use font zoom when the rest of the world has moved on to page zoom?

And I also don't know why you say nesting pixel-based components are a nightmare. Dimensions work exactly how you think they will, relative to the page.

On the other hand, nesting em-based components is a nightmare, because they jump crazily in size. You never want your date picker jumping 2x in size just because you placed a button for it inside of a larger header row vs. inside of a smaller form line. In fact, that's the whole reason Bootstrap migrated from em to rem, precisely not to have that problem.

Em-based components are really only appropriate for the most trivial typographical "components" if you can even call them that, like a bullet or tiny badge or something that gets used in different sizes of text. Certainly not components you would usually nest.

> and also that your preference is extremely uncommon

I'm still confused about this. You're commenting under an article that specifically calls out font-based zooming and differing font-sizes between devices as a problem in native environments. If it was as rare as you say, why is the writer upset about it? Do people only customize their fonts in Gnome/Mac, and never on the web? Nobody wants their browser to inherit system settings? Firefox didn't even have an option to set a default zoom on every webpage in the style you describe until early 2020.

I mean, you can say this is uncommon and I'm in a bubble, and maybe you're even right, but I feel like at some point I'm going to want to see some stats on that, because I'm not sure I believe you.

> On the other hand, nesting em-based components is a nightmare, because they jump crazily in size. You never want your date picker jumping 2x in size just because you placed a button for it inside of a larger header row vs. inside of a smaller form line.

Depends heavily on the component; this is why both `em` and `rem` units are useful. But it's not that uncommon to want nested elements like a date picker to scale.

My experience (doing a fair amount of front-end work in my day-to-day job, and writing a ton of CSS from scratch) is that (particularly when I'm writing in BEM style) I use `em` more often than `rem`, even for complicated components. But yeah, I do use `rem` sometimes, it's not that uncommon. It depends a lot on what you want the behavior of a component to be.

> In fact, that's the whole reason Bootstrap migrated from em to rem, precisely not to have that problem.

Two things. First, they didn't migrate to pixels, they're still inheriting their font sizes from user/browser preferences. In fact, Bootstrap in part moved to `rem` specifically to get away from pixel units in multiple parts of the codebase[0]. I don't see any sources online that claim they've abandoned the `em` unit entirely.

Second, I would very, very hesitantly suggest that maybe Bootstrap is not actually the best example of responsive design. I'm not going to get into an argument about it, it's a very impressive framework. It's just in my experience often a pain to work with, precisely for this kind of reason (among others). You nest an element in a static page and then dig through layers of classes to figure out why nothing adapts to the container it's put in. Bootstrap is very useful until you start to heavily customize anything. Just my opinion, and to be fair I have not tried out Bootstrap 5 yet.

The reason why nesting pixel-based components is a nightmare is because it forces you to care about every CSS class that sets a width in your component. It forces you to update every width and height in the component every time you want to make a change. For codebases you do control, this is sometimes merely annoying (depending on how clearly the CSS is written). But for 3rd-party styling systems, it can be a nightmare.

[0]: https://github.com/twbs/bootstrap/issues/19943

> I mean, you can say this is uncommon and I'm in a bubble

If you use Firefox, and several people around you use Firefox, then you are definitely in a bubble

First, let me just push back on the overall idea here: if your philosophy for how the web should work and what features are worth supporting is solely based on Chrome's default behavior, that's not a philosophy I want to encourage on the web, and I'm less inclined to listen to your ideas about what the web should and shouldn't do.

But whatever, that doesn't matter because Firefox also isn't the only browser that has text scaling. If you go into accessibility options for the current up-to-date Chrome browser on Android, there are 4 options you'll see:

- Text scaling

- Force pages to allow pinch-zoom

- Request simplified views

- Enable captions

What you won't see is a default full-page zoom option.

Not only does Chrome's text scaling option not uniformly do a full-page zoom, it also appears in my tests to selectively target and resize fonts only in certain elements on the page based on whatever unspecified algorithm Google is using to decide what does and doesn't count as a "paragraph". This means that as a designer you're not just being forced to handle multiple font sizes when you lay out a mobile site, you're also being forced to handle font sizes that scale non-uniformly across your page.

Are we going to argue whether the accessibility options in the default Android web browser are a bubble? I don't see what data people have that is making them so confident that nobody uses text scaling, because as far as I can see text scaling is a feature in every mainstream browser and is predominantly advertised on mobile devices. Is it really, genuinely weird that some people might take advantage of it?

> I've never once seen it in the wild, MDN's page for font-size certainly doesn't mention it, and I've never seen it listed anywhere as a best practice.

This is usually called “fluid typography” and in my experience is a pretty widely-known technique, but tends to be treated more as a “holy grail” because it’s difficult to get right and browser support for the various techniques hasn’t been great. Most people/teams tend to just aim for pixel-perfect design at a small number of breakpoints.

What is the use case for font-only zooming?

I just tried it on a few sites and it either doesn't change much/anything or breaks stuff -- either by overlapping text, or not increase the width of text zones so you end up with few words per line in the middle of the screen which was particularly bad on a newspaper site (along the ridiculously undersized article photo).

I thought it could save some space in headers and such if they don't zoom those, but if they used ems everywhere as might be best practice then there's no win to have.

So it's either the same or worse than full-page zooming in every test so far. This is not only a now-obscure feature, it should be considered deprecated imo -- zooming (or changing default) font size feels like hijacking a responsive web page source and hoping for the best.

> either by overlapping text, or not increase the width of text zones so you end up with few words per line in the middle of the screen

Those the problems that I mentioned. Those problems are why you don't use pixels instead of `em` units.

If you increased the font size in a PDF then columns, diagrams, and layouts would also break. But you wouldn't be surprised because you don't expect the PDF to be responsive. We expect the browser to be responsive.

The use-case for font-only zooming in general is that as a designer, there are elements that should scale with the font and elements that shouldn't. Full-page scaling works by acting like the browser is just a lower resolution, so everything scales upwards except percentage units and viewport units, including things like border widths, spacing between columns, etc... Sometimes as a user that's what you want. Sometimes it's not.

As a designer, it's useful to be able to have more control in the scenario where a user wants to scale only the font and not the border-width of an element to make something that genuinely feels responsive, rather than to be completely subject to a zoom method that is just pretending you're on a screen half as large and then upscaling before it renders.

It's also useful because we'd like to build the web into an extensible platform that users can interact with in creative ways. So maybe we'd like the ability to scale only part of a webpage. Maybe we have an extension that allows us to quickly zoom in and out of a paragraph.

Note that this is not completely theoretical, Firefox already lets users set minimum font sizes. If I set a minimum font-size of 14px, it doesn't matter if you say that your font-size is 8px, it will render at 14px -- but all of your bigger titles and headers will be unaffected. That's the kind of feature that works if browsers allow font-based zooming, and pages are built to accommodate that, but that is impossible to do if the only way we can resize a page is with full-page zooming.

What worries me is the testability. Too many variables, especially external unpredictable ones injected by browsers and user stylesheets, means accessibility testing combinations explode further than they already are.

Full-page zoom - something I imagine was less common in the past for performance reason - is much more in line with "how the site was made, intended to layout as, and tested for."

It's nice that the HN header bar doesn't grow on font-zoom, but it's hardly a killer feature (edit: and isn't even supported on my iPad where I'd want it). I always full-page zoom and was never bothered by it or even noticed it. But clearly half the web is broken for font zoom. I'd say don't fix it, leave it behind instead. Just like 14px doesn't really mean 14px anymore and that's ok.

> What worries me is the testability.

This is why you should keep it simple :-)

This is the web, not print publishing.

Follow the rules, then to save save some time test with default settings in Firefox or Safari or iOS, the point is that the most usual problem I've seen the lastest few years are Chromeisms - non standard behavior that happens to work in Chrome.

>I just tried it on a few sites and it either doesn't change much/anything or breaks stuff

This tells you you're visiting a site who's designer(s) don't want the user to control their browser. Ask them and dollars to donuts they'll treat it like the "doctor, it hurts when I do this" joke.

Look at the vitriol in the comments here, there is unmistakeable antipathy toward the user. Nobody is going to say they pride themselves on a user-hostile approach to web design, but a duck is still a duck and the vast majority of designers are still going to think in terms of pixel-perfect.

"When you're slapped you'll take it and like it." --Sam Spade

I set my fonts larger in Android sepecifically... I can still double-tap/zoom if I need larger images. It's the reading that tends to be the most problematic.

I'm far sighted, so see most things without glasses fine.. I have glasses at my desk, but don't tend to have them on me when out/about and trying to use my phone.

Chrome on mobile absolutely has a text zoom, it's exposed as an OS function, but chrome respects it... my vision is not great, so in accessibility settings I have fonts set to largest. Chrome does a decent job (as most Android UI) of respecting this. The apps that don't, or don't do it well (Facebook) are the ones that are particularly annoying.

It may not be exposed in the browser directly, but the functionality is definitely there.

edit: and I'm frankly okay with using px/pt for the baseline font at the root level and using em/rem elsewhere. In the end, I understand that it should be 72pt/in and 96px/in as far as CSS goes... others may not... Devices that don't have their actual PPI set so browsers can properly calculate the CSS dimensions is slightly annoying though. But that's been a bit craptastic forever and a day.

In the end, nothing will ever be close to perfect. I do find it annoying that different fonts with the same size and line-height will render far differently... a 12pt font should render (roughly) 6 lines per inch.

> now that it's generally recommended to use rem over em anyways.

Whoa! Apparently I missed the note on that one. I very much favor using em over rem precisely because it is relative to the current font size. This is especially nice with SVG icons:

    <h1>
      <svg class="svg-icon"><use href="sprite.svg#my-icon" /></svg>
      Some Heading
    </h1>

    h1 {
      font-size: 1.5rem;
      color: rebeccapurple;
    }

    .svg-icon {
      fill: currentcolor;
      height: 1em;
      width: 1em;
    }

Do you care to tell me why em units are not recommended anymore, and who it is recommending rem in favor of em?

Your specific example is an exception to the "rule". The em measure is relative to the font size of the last containing element that specified an explicit font size. So with a heading, a 1em x 1em icon makes sense because it'll be the height of the container h1 element (which you set as 1.5rem).

The rem unit is relative to the base document font size. Your icon in an h1 set to 1rem x 1rem would be sized relative to the body's base font size. In your example a 1rem icon would be .66 the size of your h1.

When you use rem units consistently their size is more predictable throughout the document. If you've got a complicated stylesheet overriding sizes all over the place em units can end up inconsistently sized and tricky debug. I've seen rems recommended for probably the past ten years or so.

I think there are many of these “exceptions”. At the top of my head:

* Make inline code (say: `0.85em`) relative to fit equally nicely in a big heading or in a smaller `<aside>`.

* Margins and paddings so that larger font sizes have more spacing between them and more breathing room

* Column width where you want to fit a certain amount of character at most in a single column (say `grid-template-columns: repeat(auto-fit, 30ch)`)

* Max container width of a text heavy container is probably best specified in `ch` units (say `max-inline-size: 120ch` is a good one) as long tines are hard to read. If you later decide to use a larger font, you don’t need to change this value like you would have if you’d use `rem`.

I could go on... But I really doubt this is a good rule. And I am skeptical that any serious front end developer is recommending against units that are relative to the current font size.

>Nobody does that anymore.

It's used as an accessibility option for people with low visual acuity.

Nobody does that anymore. /s

> Nobody does that anymore.

I use Ctrl+'+' all the time to zoom text.

The default behavior of Ctrl-+ (and the only behavior in Chrome, Safari, Edge) is different from Firefox's "Zoom Text Only".

Just hitting Ctrl-+, it eventually switches to the mobile stylesheet https://i.imgur.com/E7rAR37.png

With "Zoom Text Only", the layout partially breaks and you get columns of text with only one word per line https://i.imgur.com/C5NiyFA.png