If you were to use ems here, the values would have to change. This is because a max-width of 40em on body copy that is set to 100% will give you a calculated width of 640 pixels (40 times the default text size of 16px). Apply the same to a heading that has a font-size of 3em and you have something totally different: 40 times the heading size, which is 3 times the default 16px: a total of 1920px. But you can set the text size in whatever unit you want, and set the max-width as 40rem, and both the heading and the body copy would have the same equivalent maximum of 640.
Where you may want to use ems is where the measure should be equivalent and proportional to the text. So the margin between paragraphs is a good example. A margin-bottom of 1em will always give you that one line break in between paragraphs, not matter what size the text. Likewise padding on a button or form element: set the padding in ems so that no matter what happens with text scaling, the relationship between the text and the containing element remains consistent and proportional.
A view(port) to a kill
I first saw viewport width units applied to text size in a talk by Jen Simmons in 2014 or so, and it sort of blew my mind: a headline scaling smoothly with the window size, without requiring any Javascript shenanigans. The issue I saw eventually was due to the scaling being constant. This could lead to a heading scaling down below body copy size on a very small window (I minded the fact that it would keep scaling up ad infinitum a lot less). This would lead to strange things happening with content hierarchy. But nonetheless, it was really compelling.
A year or two later, Tim Brown published a piece about what he termed ‘CSS locks’ where he came up with some math that, in combination with media queries, could yield a scaling typographic system that effectively had a low and high end limit to the scaling, tied to specific breakpoints. I started playing around with this quite a bit last year, and will be digging deeper into that in my conference talks and workshops this year, and in future editions of this newsletter.
Sometime in the past few months I also came across a observation from Estelle Weyl that had never occurred to me: sitting text with vw units completely breaks page zoom, since every time you zoom, it simply recalculates and scales the text all over again: based on the window size. I found a reference to this on Mozilla’s MDN site when looking up calculations, and it turns out that’s what was saving my flexible typesetting from accessibility disaster! It involves both vw units and ems, so user preferences and page zooming remain intact. It’s a great way to get the scaling fluidity of vw units without sacrificing accessibility.
Wrapping it up with a relatively sized bow
One of the things Ethan Marcotte advocated in his book Responsive Web Design and subsequent writing was to avoid pixel measurements entirely. Base everything around the size of your text and percentages of the viewport width, and the design will scale well in proportion just about everywhere. And I’ve stuck with that ever since. The only place I think pixels have a home is in defining border thickness. And even there, you can use ems or rems just as easily. With all the differences in pixel densities of displays—to say nothing of the variation in dimensions—it just makes sense to pick the core element on the page and size everything relative to it.
My rule of thumb has generally been percentages for layout widths, and ems or rems for any vertical measurements, or for margins between elements. That way it helps maintain some sense of rhythm related to the size of the text, even if you don’t go so far as to try and follow some sort of text-size-related baseline grid system.
I hope this has been helpful. I know that standardizing on this it has helped immeasurably with large teams and big projects in helping maintain consistency and reduce QA and testing time. It does require a slight attitude change and more flexible outlook: there will never be an exact match to a comp. But that’s a good thing. A comp is not a website. It’s a picture of a website, frozen in one moment and browser width.
The rest is up to us to interpret as we put it into code.
|