Using px for root nullifies browser font-size

[keithjgrant]

I know this has been hashed over in the past, but I don't see any discussion about it for v4. Using px for the root font-size invalidates the user's font-size settings in the browser. This really should be defined in em/rem/%. The thought that bootstrap will be stripping away this functionality from users on a large portion of the web is unsettling.

Yes, I know that zoom still works, but this is a temporary, per-tab setting. Users with low vision are the one's most likely to need to increase their font size, and they will need it increased all the time, permanently. The shouldn't have to zoom in again every time they open a new tab.

Rems are broadly supported now. Use those on the root element. I see no benefit to favoring pixels on the root, particularly when the framework uses ems and rems liberally everywhere else.

[patrickhlauke]

I'd tend to support this, FWIW

[cvrebert]

Yes, I know that zoom still works, but this is a temporary, per-tab setting.

But doesn't your screenshot show the exact opposite?

[keithjgrant]

But doesn't your screenshot show the exact opposite?

I... uh...
/me looks around sheepishly

Yes. It totally does. I guess that's what I get for deciding to stick that on at the last second.

In an effort to save face a bit, I’ve done a little more digging. Most browsers don’t actually expose the zoom settings on a settings page, but using the hotkeys or view menu to change zoom seems to persist in IE9 and Firefox. Documentation I found on IE11 and Edge seems to indicate those behave similarly. Chrome is a bit of an oddball. Using the view menu or hotkeys is temporary, as I indicated in the text of my original post, but it also allows you to customize zoom AND font size on the settings page (e.g. that screenshot), which is lasting.

I guess that does reduce the severity of this issue. But I do think nullifying the font-size setting, at least in Chrome seems off to me. Especially when we seem so close to supporting it.

[cvrebert]

Especially when we seem so close to supporting it.

The pessimist in me, having seen various unfixable bugs related to non-pinch page zooming, suspects that something would break, but that's just a feeling. I would love to be proven wrong by empirical data.

(The other pessimist in me imagines that some designers might arbitrarily hate browsers' default font sizes (or the possibility of the defaults being inconsistent across browsers), but maybe designers are in reality more reasonable than I sometimes feel like they are.)

[keithjgrant]

By sheer coincidence, an article on this topic was in the Responsive Design Weekly newsletter this morning: http://nicolas-hoizey.com/2016/03/people-don-t-change-the-default-16px-font-size-in-their-browser.html

[nhoizey]

Happy to see my article is useful! ;-)

[elessar-ch]

I absolutely agree that the font-size should not be set on html but that the users choice should be respected. Implementing this in bootstrap 4 might in the end actually be valuable for so many users and mark a turning point on readability in the world wide web as so many developers will use it.

What I don't understand is why we would fix the font-size on root to 16px and then use the rem unit in classes? It's just a hassle because when I talk with my designer colleagues they usually only know pixels (and at this point I don't blame them). So if we're not using the browser rem value, I'd use pixels everywhere.

[leggomuhgreggo]

Anyone hip to the details of how setting root font-size prevents user preferences? I'm coming from a place of ignorance here; so forgive me if this sounds asinine, but it seems like it'd be fairly trivial for the browser (or other accessibility tool?) to override the root by multiplying current root font-size value by the percentage the user has specified.

It'd be great to be able to continue using rem as a responsive, css-locked variable, if possible.

@fvsch

[fvsch]

Anyone hip to the details of how setting root font-size prevents user preferences?

Sure. This code doesn’t follow the user’s base font-size preference:

:root { font-size: 16px; }
h1 { font-size: 1.5em; /* = 24px */ }

and this one does:

h1 { font-size: 1.5em; /* = might be 24px,
  or smaller/bigger depending on user preference */ }

Since default browser styles do make use of this user preference, overriding that behavior by using px or other non-relative units for font-size is generally considered as “preventing a user preference” and back in the old days it was evil and would fail you on any accessibility test. Nowadays people are html {font-size:10px}ing like there’s not tomorrow. Different times I guess.

it seems like it'd be fairly trivial for the browser (or other accessibility tool?) to override the root by multiplying current root font-size value by the percentage the user has specified

Indeed the User Agent is free to disregard some if not all your CSS or JavaScript code, so they can offer features such as:

1. Firefox Desktop: “Zoom Text Only” + 150% zoom level will multiply all calculated font-sizes (and possibly line-heights, letter-spacing etc.) by 1.5.

… and that’s about the only one I know of. Other desktop browsers and most or all mobile browsers don’t offer that kind of feature. (Opera used to have several such features before they jumped ship to Blink.)

Note that only overriding author styles for the root font-size would be a tad too specific and limited, since author styles can use absolute units for font-size at any step in the document.

[leggomuhgreggo]

Man, I feel like a dummy--was confused and thought that all root font-size definitions broke user preferences. Thanks for the considerate response @fvsch.

I guess I'll just +1 this and propose that, since 16px is (essentially) standard, the scss be updated to something like this:

html{
  font-size: percentage($font-size-root / 16px);
}

Thanks!

[mdo]

Are there any risks or pitfalls to switching this out for us? If someone wants to submit a PR, I'd love to see some testing across browsers of all our major component.

[fvsch]

There are two possible strategies:

// 1. Mandate that $font-size-root should be defined in pixels, always
$font-size-root: 16px !default;
html {
  font-size: percentage($font-size-root / 16px);
}

// 2. Mandate that $font-size-root should be a relative value, while allowing
// other units.
$font-size-root: 100% !default;
html {
  font-size: $font-size-root;
}

The downside of the first solution is that, if users set $font-size-root to a value not in pixels, they will get a Sass error (hopefully). The upside is that you’re sure to get a percentage value in the end.

Downside of the second solution is that users can change $font-size-root to a pixel or other fixed value. The upside is that if they really need to (e.g. for compatibility on an existing website), they can. :D

Are there any risks or pitfalls to switching this out for us?

The main risk is if you have components with widths defined in rem and media queries defined in pixels. I’ve seen that with a Bootstrap 3 modal component.

@media (min-width: 640px) {
  .modal {
    width: 60rem; /* expecting 1rem = 10px */
  }
}

Use that on a page where 1rem is some bigger value (16px, 20px…), and things go bad real quick.

[mdo]

Opened #21524 for this.