Using px for root nullifies browser font-size #19460

Closed
keithjgrant opened this Issue Mar 10, 2016 · 13 comments

Projects

Todo in Alpha 6

8 participants

@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.

screen shot 2016-03-10 at 9 27 06 am

@patrickhlauke
Member

I'd tend to support this, FWIW

@cvrebert
Member

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
Member

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
nhoizey commented Mar 13, 2016

Happy to see my article is useful! ;-)

@elessar-ch
elessar-ch commented Aug 8, 2016 edited

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
leggomuhgreggo commented Sep 28, 2016 edited

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
fvsch commented Sep 28, 2016

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 mdo added this to the v4.0.0-alpha.6 milestone Oct 24, 2016
@mdo
Member
mdo commented Oct 24, 2016

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
fvsch commented Oct 24, 2016

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 mdo added the has-pr label Jan 3, 2017
@mdo
Member
mdo commented Jan 3, 2017

Opened #21524 for this.

@mdo mdo closed this in #21524 Jan 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment