On borrowing Apple's type scale

I’ve updated the typography on this site to use Apple’s macOS and iOS type scales. Interface body text is 13 on the desktop layout and 17 on compact or touch layouts, with titles, captions, and supporting text drawn from the same systems. Article bodies, including Weekly Links, keep the larger 17 equivalent on desktop too.

Those numbers might look a little odd if you’re used to keeping everything divisible by four. I’m quite comfortable with that. I wanted a clearer relationship between the different kinds of text on the site, and a spacing grid wasn’t going to decide that for me.

What I wanted from the system

A personal site has several kinds of reading happening at once. You might be scanning project summaries, finding a link, or settling into an article. Giving all of that the same treatment makes it harder to tell what deserves your attention, but choosing a new size for every component creates a different kind of inconsistency.

Apple’s text styles gave me a useful starting point because they’re organised around jobs: Body, Headline, Subheadline, Caption, and the various titles. Each style brings a relationship between size, weight, and line height. A headline can share the body’s size and still establish a different level of emphasis through its weight.

I wanted to bring that way of thinking into the site whilst keeping my own typefaces. The more compact macOS scale gives the desktop layout a density I want, and the iOS scale provides more generous text on compact and touch layouts.

The distinction follows the layout and input capabilities rather than detecting your operating system. The compact scale is the default. The desktop scale applies when the viewport is at least 64rem wide and the primary input supports hovering and fine pointing. A narrow Mac window therefore gets the larger text, as does a wide tablet whose primary input is touch.

This is a choice about how this site should behave. It isn’t a claim that websites ought to look like Mac apps.

The grid doesn’t choose the letters

I like having constraints. A spacing scale reduces the number of decisions I need to make and makes it easier to keep related elements together. Multiples of four are convenient to work with, particularly in a drawing tool where the values are always visible.

But that convenience doesn’t tell me whether a paragraph should be 16 or 17, or whether a heading needs more weight instead of another increase in size. A four-pixel grid can’t account for the proportions of a particular typeface or the amount of text someone needs to read.

Apple’s own defaults are a useful reminder here. Its legibility guidance gives 13pt as the default for macOS and 17pt for iOS and iPadOS, alongside different defaults for its other platforms. There are even and odd numbers throughout its scales. Divisibility isn’t the organising principle.

On the web, the value in your design file is only part of the eventual result anyway. Browser preferences and zoom can change the size someone sees. Responsive calculations can produce fractional values. There’s nothing inherently wrong with a computed size of 31.293px, though the decimal places don’t make it inherently good either. You still have to look at the text and understand why it has that size.

This is one of the reasons I think designers should understand the technologies they’re designing for. It gives you more useful questions to ask than whether a number looks tidy in the properties panel.

Borrowing the scale takes some judgement

Apple’s native point sizes aren’t CSS points. I’ve carried their numerical values into CSS pixels at the browser’s default root size, expressed in rem. The compact Body value is 1.0625rem, and the desktop interface value is 0.8125rem. Article reading text uses 1.0625rem on both layouts. The root size stays relative to the browser’s default, so those values can respond to the reader’s browser font preferences.

I also wanted the site to respond when someone has already asked their device for larger text. Leaving the root size alone respects browser font preferences, but it doesn’t reliably connect a website to the iPhone’s Larger Text setting. That needed an explicit addition.

I’ve added the emerging text-scaling opt-in:

In browsers that implement it, relative text sizes can follow the reader’s system and browser text preferences. Support is still developing, so I’ve also added a fallback for older iPhone and iPad WebKit browsers using Apple’s Dynamic Type Body style.

The fallback measures that style separately from the page. If the system returns a Body size of 23 instead of the default 17, it applies a multiplier of 23 / 17 to our relative root size. At the default setting the multiplier is one, preserving the site’s existing sizes and custom fonts. It checks again when the page returns to view or the window resizes. Where the browser exposes the standard text-scale environment variable, the fallback steps aside to avoid applying another multiplier.

This doesn’t give the site every behaviour of a native Dynamic Type interface. In the fallback, the existing text roles scale together rather than following Apple’s separate scaling curves for each style. It also doesn’t give us universal access to desktop system preferences; those still depend on what the browser supports.

At larger system sizes, I’ve moved the course link into the navigation menu so it doesn’t crowd out the other controls, bounded the surrounding spacing, and allowed article labels to wrap. Simply making the letters larger wasn’t enough.

I’ve checked the default layout in browsers and exercised the fallback with simulated system sizes, including the largest iOS Body value. Those checks don’t establish how a physical iPhone responds to a settings change. The web accessibility requirement is that people can enlarge text to 200% without losing content or functionality, and testing the actual settings remains part of assessing the result.

I’ve also kept more room between lines in articles than the native Body styles specify, with a unitless line height of 1.65 and a maximum reading width of 65ch. Long passages need consideration beyond the size of an individual line.

The first pass also needed refinement. Some descriptions and controls had ended up with different roles despite doing similar jobs. Making more of them Body-sized corrected inconsistencies, but then supporting information competed with the content it qualified. I had to work through those relationships: a project summary carries the main information, whilst a contribution note supports it; an article title needs more emphasis than its excerpt.

That was a useful part of the change. Having a named scale made those decisions easier to describe, but I still had to make them.

I’ve made one deliberate exception to the native scales: article bodies use the 17 equivalent on desktop as well as mobile, including Weekly Links. Reading a whole article asks more of the text than scanning a navigation label or a project summary, and I want a more generous starting size for that longer reading. Apple’s 13pt macOS default is a useful reference for interface density, but it doesn’t settle the right size for an essay in my custom font.

That exception stays within the article body, including the version opened in the writing sheet. The desktop interface keeps its more compact scale, and the reader’s text preferences can still enlarge either one. I don’t want someone to have to reach for zoom just to get a comfortable starting point for an article.

For now, I’ve kept these body sizes fixed within each layout rather than making them fluid with the viewport. A CSS calculation can be useful when there’s a reason for text to grow with its container, but I don’t want an article’s paragraphs changing size simply because a window gets taller. I want to make those decisions by reading the page, checking the hierarchy, and seeing what happens when the reader changes the conditions.