search

18F / frontend

18F's Front End Guild –  content has been moved to https://github.com/18F/development-guide
Other
121 stars 29 forks source link

Revisit recommendation on font-size units #118

Open noahmanger opened 8 years ago

noahmanger commented 8 years ago

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.

msecret commented 8 years ago

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.

msecret commented 8 years ago

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

msecret commented 8 years ago

18F/Gov:

maya commented 8 years ago

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

html {
  font-size: 100%;
}

body {
  font-size: 62.5%;
}

?

adborden commented 8 years ago

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

noahmanger commented 8 years ago

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.

adborden commented 8 years ago

On Thu, 2016-04-28 at 10:36 -0700, Noah Manger notifications@github.com 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

maya commented 8 years ago

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

noahmanger commented 8 years ago

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.

maya commented 8 years ago

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?

msecret commented 8 years ago

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.

msecret commented 8 years ago

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.

maya commented 8 years ago

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.

msecret commented 8 years ago

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.

msecret commented 8 years ago

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.