Dynamic Type on the Web
This site now supports Dynamic Type on iOS and iPadOS. If you go to System Settings on your iPhone or iPad, and change the setting for Display & Brightness > Text Size, you’ll see the change reflected on this website.
This is a big win for accessibility: many folks make this adjustment on their device to match their abilities. Just because you can read a tiny font doesn’t mean that I can. It also is a win for consistency: my site’s font size matches the other text that a visitor sees on their device.
The best part is that this improvement can be realized with only a few lines of CSS:
html { font-size: 0.9em; font: -apple-system-body; font-family: "Avenir Next", "Helvetica Neue", sans-serif; }
Note that his site gets the system sizing but does not have to use the system font.
Previously:
Update (2024-07-08): Jeff Johnson:
The text is kind of small on the Mac.
That’s macOS setting a default value that’s too small. (And I cover some mitigation in the post.)
I’d like it to be higher. But doing so punishes people on mobile devices who aren’t using Safari. This is what it looks like on Android.
I’m not holding out on this being a standard outside the Apple ecosystem because AFAIK there isn’t a notion of Dynamic Type on other platforms.
The failing here is Apple not implementing it on all of their platforms.
5 Comments RSS · Twitter · Mastodon
Ed: When it‘s recognized (in browsers powered by mobile Safari) “font: -apple-…” overrides the preceding “font-size”. In this scheme the preceding “font-size” is there purely to provide a fallback value to other browsers.
@Alexandre Yes, that's what I thought: it's only works in (the latest) Safari. It's neat and I wish other browsers had it too, but as it is, it seems unsuitable for public websites.
It‘s pretty unsuitable as you have to design your font scaling twice, which is hell, but it can be done.
The mentioned “failing” isn‘t Apple not implementing it everywhere, the failing is Craig designing first for a niche proprietary web feature instead of the other way around.
You can use the usual responsive techniques and then special-case for iOS using a "@supports (font: -apple-system-body)" feature query. (Or the other way around with "@supports not (…)" if designing for iOS first.)
@supports makes for much cleaner CSS in general, playing with overriding-or-not declarations across browsers is an obsolete technique.