week11y issue 134

Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:

Why you should never use px to set font-size in CSS

Josh Collinsworth dispels the myth that it doesn’t matter whether you use px, em or rem for your font sizes.

Whilst px stands for “pixels”, it no longer translates into physical pixels on the screen, as browsers scale up pixels on higher resolution screens. “Pixels on the iPhone 14 Pro are so microscopic that 16px, in literal device pixels, would be about the size of printed type at 2pt font size”.

em once referred to the physical size of an “m” character, but now refers to “current font size”. rem stands for “root em“, and refers to the root font size. By default, 1 em and 1 rem are equal to 16px (the default font size of most browsers). But whilst 1 rem generally remains at a constant 16px, the ‘pixel size’ of 1 em changes based on its context.

With the CSS .container { font-size: 200% } and .container p { font-size: 1em }, the 1em here will actually render as a 32px size, not 16px.

Understanding how this works is the key to unlocking why defining font sizes in px is a bad idea. em and rem work with the user’s font size – the user can change the browser’s default font size and everything will scale accordingly. Defining font sizes in px overrides the user’s choices.

The misconception most likely comes from this: developers zooming in to test their web page, and noting that fonts seem to scale up and down irrespective of the unit type used. However, not everything scales in the same way.

If you set CSS of p { border-bottom: 2px solid black; margin-bottom: 20px }, and then change the default browser font size to 64px, you’ll see some large text, but the surrounding spacing and borders don’t scale with it. Setting these values with em or rem would mean they would scale with the text. Zooming in and out does scale the border and spacing, but it’s so undersized compared to the root font size that it looks terrible. See screenshots in the article.

For similar reasons, it’s important not to use px in your media queries. If the user overrides their root font size, you may find that your breakpoint does not trigger at the width that you expect it to.

Josh summarises with a recommendation to use rem by default, only using a smattering of em where it’s important to make something relative to the size of its container, and only using px for certain aesthetic elements that you would not want to scale with the user’s font size.


https://randoma11y.com/

A helpful utility for generating accessible color combinations. View the project on GitHub or follow it on Twitter.


Why we need CSS Speech

LĂ©onie Watson describes how all modern browsers allow you to “listen to content”, either natively or through some plugin/extension, and how developers currently have very little control over how content gets read. “In the same way an organisation chooses a logo… it stands to reason that they may also [wish to] choose a particular voice that represents their brand”.

Speech Synthesis Markup Language (SSML) is intended for this purpose, but involves mixing in special markup inside your HTML. LĂ©onie argues that this returns us to the bad old days of having to mix styling into our HTML, before CSS allowed us to separate content from its presentation. (By the way, SSML isn’t supported in any browsers yet).

LĂ©onie points us to the CSS Speech Module. It is a W3C Candidate Recommendation, thus has not yet achieved the status of W3C Recommendation. In short, it proposes a set of CSS properties to let authors define the aural presentation of content, whether read out by someone’s screen reader, a browser’s read-aloud capability, or a platform Text To Speech (TTS).

The speak: property would act like the display: property; the latter determines whether an element is visible, and the former would determine whether the element should be spoken. These would be linked; if an element is set to display: none, for example, then the element would also not be spoken, unless an override is provided. Other properties proposed include voice-family, voice-pitch, voice-rate and voice-volume.

LĂ©onie is hoping to edit the CSS Speech module, stripping it down to its bare minimum, as the current proposal is “too big, too wordy, and has too many features”.


Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.

Loading...