frontend Revisit recommendation on font-size units

Currently the frontend guide recommends setting global font-size in pixels:

html {
  font-size: 10px;
}

And then setting everything else in REMs.

In FEC Style we follow the recommendations originally described here and set:

html {
  font-size: 62.5%;
}

This defers to the default font-size users set in their browsers, rather than overriding it to a pixel value (a usability and accessibility win, AFAICT).

But! As @adborden points out here, this poses issues when trying to integrate our style repo with other libraries that depend on font-size being set to 100%.

I haven't kept up-to-date on the current thinking around best practices on this, so I'm not sure what to do. But wanted to open an issue for discussion.

Apr 06 '16 16:04 noahmanger

There's a pretty similar discussion to this going on here: https://github.com/18F/web-design-standards/issues/992

I'm leaning towards the opinion that you shouldn't touch base font size (leaving it at 100%) and just deal with some math when you use rem and em values. From reading different things, I'm not sure there is a best practices, seems like many people are doing different things.

One thing as mentioned in the standards issue: there are potentially accessibility/browser issues when you set your base font size to a px (and maybe even percentage) value. As an organization that highly values accessibility, I think it should be of higher priority then developer ease when determining our standards on this.

Apr 06 '16 18:04 msecret

Some research on what other sites and style libraries are doing:

Salesforce Lightning design: 100% on <html>, 875rem on <body>
Bootstrap: 10px on <html>, 14px on <body>
CFPB: 100% on <html>, 100% on <body>
Foundation: 100% on <html>, 100% on <body>
Pure.css: no font rules
Materialize: 15px on <html>, none on <body>
GDS 62.5% on <html>, 160% on <body>
Code for America none on <html>, 16px on <body>
Lonely Planet 0.75em on <html>, none on <body>
MailChimp: 100% on <html>, 100% on <body>
MapBox: 100% on <html>, 100% on <body>
A List Apart: 18px on <html>, 18px on <body>
BBC 100% on <html>, 62.5% on <body>
Sunlight Foundation: 100% on <html>, 14px on <body>
IBM: 100% on <html>, 100% on <body>
Mozilla: 100% on <html>, .875rem on <body>
OpenTable: 10px on <html>, 100% on <body>
Pivotal Web Services: 10px on <html>, 16px on <body>
Khan Academy: 100% on <html>, 14px on <body>
All values were taken from over 1200px screen size and from the base stylesheets on the link.

Apr 28 '16 00:04 msecret

18F/Gov:

18f none on <html>, 1em on <body>
CAP 10px on <html>, 16pt on <body>
CALC 62.5% on <html>, 1.5em on <body>
MyRA 18px on <html>, none on <body>
Every Kid in a Park none on <html>, none on <body>
USEITI 100% on <html>, 1rem on <body>
Peace Corps 62.5% on <html>, 1.5rem on <body>
OpenOps 10px on <html>, 14px on <body>
College Scorecard 100% on <html>, font-size(1)? on <body>
Discovery 100% on <html>, none on <body>
Pulse none on <html>, 0.875em on <body>
Analytics none on <html>, 18px on <body>
BetaFEC 62.5% on <html>, 1.4rem on <body>
ERegs 100% on <html>, 1em on <body>

Apr 28 '16 16:04 msecret

@noahmanger do the issues with other libraries still happen if you set:

html {
  font-size: 100%;
}

body {
  font-size: 62.5%;
}

?

Apr 28 '16 17:04 maya

@maya, thanks! I'll try that out..

Apr 28 '16 17:04 adborden

Hmm. Yeah worth a shot. We set a lot of the spacing and component font sizes as rem, which will change the way the fec-style stuff is sized if html { font-size: 100%}, right? But maybe it would be better to set more of that with ems.

Apr 28 '16 17:04 noahmanger

On Thu, 2016-04-28 at 10:36 -0700, Noah Manger [email protected] wrote:

Hmm. Yeah worth a shot. We set a lot of the spacing and component font sizes as rem, which will change the way the fec-style stuff is sized if html { font-size: 100%}, right? But maybe it would be better to set more of that with ems.

Yeah, my thinking was that using ems, you could scale a component's size just by changing the font-size of that component. Increasing the html size would similarly scale up all the components.

When using rems, you don't have have the option of adjusting a single component. I've never built a component library before, so I don't have much practical experience here.

Aaron D Borden Human and Hacker

Apr 28 '16 18:04 adborden

@noahmanger on WDS, we currently have what I posted above and 1rem still equals 10px. You end up having different base ems and rems, tho. I just posted it above to see if it would help in the meantime with your issue.

That being said, we're still exploring if this is the right overall solution, given everything @msecret posted.

Apr 28 '16 18:04 maya

Ah! I didn't realize that. In that case, it might just work :finerscrossed:.

Yeah, I'm sure there's a smart way to do sizing by balancing rems and ems to get some of the cascade benefits @adborden . The challenge is always having unintentional cascades, a problem that rem sizing is meant to fix.

Apr 28 '16 18:04 noahmanger

Ok, turns out we still set html to 100% on WDS, but have been thinking about doing what I posted above, we just didn't arrive at a solution yet. I think what I posted was backwards: if you used that, 1rem = 16px (or browser settings) and 1em = 10px. To answer your question @adborden, rem would come form html and em would come from what was set next or 62.5% in this case.

Is that right?

Apr 28 '16 18:04 maya

Thats an interesting idea: have each component set it's own font-size and then have all measurements in the component be em so it won't break when the html font size changes. That being said, the more global tag based rules would still break because they'd be off the global size.

Apr 28 '16 18:04 msecret

I'm also not sure I like the solution of using ems on one style library and rems on another just to ensure they can work with each other. I think ems and rems both have valid use cases within a site, so that feels to be breaking how you could potentially use them successfully.

Apr 28 '16 18:04 msecret

I don't know that setting a font size for every single component is the right way to go either, feels like you'd want a typographic system that serves all components in a predictable way.

Apr 28 '16 18:04 maya

The solution here could even be more brute force: set a standard across 18F and create tools to make it easier to modify all your existing font sizes in your code to update to the standard.

Apr 28 '16 18:04 msecret

Next steps: we have to determine the accessibility concerns with setting a global font size in px and in % (they might have different concerns). This will likely mean more in depth research on what others in the accessibility and front end community have found and potentially our own research with accessibility tools and settings.

Jun 14 '16 16:06 msecret