[css-fonts-5] Dynamic text size

[litherum]

iOS includes a feature named "dynamic type" where users can increase the text size all across the OS. This is controlled by a slider in the system Settings app:

A similar feature exists on Windows. Here's a screenshot from the Windows 10 settings app:

In the iOS case, and in the Windows case too from what I can tell, this setting is applied all across the OS, but isn't applied inside content drawn by the browser. In Safari's case, this is because changing text sizes often breaks webpage layout. (Safari has a related feature called "make text bigger" that can bump up the font size on a page regardless of author opt-in, but that setting is per-site, not global.)

We've exposed this feature in Safari by using some non-standard values to the font property, and we've evangelized this multiple times to developers. However, this feature is probably something that belongs on the Web Platform, rather than being a nonstandard extension.

[litherum]

WebKit's current implementation is intended to work like this:

body {
    font: -apple-system-body;
}
h1 {
    font-size: 1.2rem;
}

This is a good place to start the conversation at.

[myakura]

Android also has the system font size feature and it appears to work just as iOS/Windows; it applies across the OS but the content inside browser.

I've wanted the font size exposed to the web. During holidays I was helping my mother setting up her phones, and she wanted the bigger UI text so I changed the size. However some contents on the homescreen were pinned websites so those "UI"s are not scaled to the size she wanted.

So I would really love to see the standardized solution. It improves accessibility for elderly people (or people with decreasing vision) and will also supports people like me who wants to make UI size smaller.

[litherum]

@myakura Yep, looks like Android has this setting, too.

[AmeliaBR]

What do you expect to be added to CSS?

This isn't really a new problem. Historically, most browsers allowed users to set preferred font-sizes; Chrome and Firefox still do. All that is changing is that the setting has moved from the browser to the operating system.

Wherever the user preference is set, it should be reflected by the browser in the default font size for the page (and the definitions of the font-size keywords like medium, as discussed in #2430).

Ideally, web page content authors would work with that user preference, using medium font (or 1rem assuming that they never mess with the root font size) for normal body text, and relative adjustments from that value for fancy fonts, headings, small text, and so on.

But web page authors, as a whole, have historically been very bad at reflecting user's preferred font sizes…

As you mention, simply overriding the font size set by the web page styles can result in broken layout and overlapping text, which is why most browsers don't override absolute font sizes. But at least some browsers (Firefox and Chrome) currently support a "minimum font size". There's no reason they couldn't adjust that automatically based on an OS-set ideal font size, if the user hadn't set a different value in the browser.

The only option that would avoid potential clashes with author styles would be for a browser to be smart about setting the overall px-zoom level for a page to effectively scale up/down body text to within a certain percentage of the preferred size. But I'm skeptical about whether this type of smarts could really be implemented correctly and efficiently, given the wide variety of font styles and effective sizes for a given em-size.

[Malvoz]

This was also mentioned in #2630 / #1693. Might aswell keep the discussion here?

[cookiecrook]

@AmeliaBR wrote:

What do you expect to be added to CSS?

A number of potential solutions could solve this problem.

Minimum Needs

1. A way for authors to opt-in to the user's preferred font size. This might be achieved using existing ways (e.g. font-size: medium though probably with another opt-in) or new ways (e.g. font-size: env(font-size) to set an element's font size (such as the body base font size) to a user's preferred default.

2. A way to ensure browsers don't force this on web sites (especially mobile sites) that are not prepared or able to fix layout issues. Turning this on everywhere will break most mobile web layouts, and make the feature unusable for the low vision users who need it the most. Potential solutions to this might include a new viewport property (e.g. supports-large-fonts or something similar) as an explicit opt-in. A new keyword (system-font-size) or accessor (env(font-size)) could also count as an explicit opt-in.

3. A way for authors to adapt their layouts to changes in the user's font-size. This should probably be handled by media queries. More on this below.

This isn't really a new problem. Historically, most browsers allowed users to set preferred font-sizes; Chrome and Firefox still do.

As does Safari on Mac. The newer problem is more specific to mobile contexts where screen real estate is more constrained.

Wherever the user preference is set, it should be reflected by the browser in the default font size for the page (and the definitions of the font-size keywords like medium, as discussed in #2430). >Ideally, web page content authors would work with that user preference, using medium font (or 1rem assuming that they never mess with the root font size) for normal body text, and relative adjustments from that value for fancy fonts, headings, small text, and so on.

But web page authors, as a whole, have historically been very bad at reflecting user's preferred font sizes…

This is the problem. Most sites would break, and the user would be forced to turn off this exceedingly useful system feature.

Apple engineers underwent a huge engineering effort in 2017 to make sure the entirety of iOS supported the extra-large accessibility font sizes. The entire Web will never support extra extra large fonts, but low vision users should have the ability to use this feature in apps and sites that take the care to do it the right way.

As you mention, simply overriding the font size set by the web page styles can result in broken layout and overlapping text, which is why most browsers don't override absolute font sizes. But at least some browsers (Firefox and Chrome) currently support a "minimum font size".

Safari has also had this preference for more than a decade. It would be irrelevant to the mobile context
unless authors were provided a way to opt-in and a way to adapt their sites.

There's no reason they couldn't adjust that automatically based on an OS-set ideal font size, if the user hadn't set a different value in the browser. The only option that would avoid potential clashes with author styles would be for a browser to be smart about setting the overall px-zoom level for a page to effectively scale up/down body text to within a certain percentage of the preferred size. But I'm skeptical about whether this type of smarts could really be implemented correctly and efficiently, given the wide variety of font styles and effective sizes for a given em-size.

There are a number of common layouts that would make existing CSS impractical or impossible on small viewports. I'll start with a straightforward example previously pitched to the CSS WG.

/* Default layout uses 2 columns */
main {
    columns: 2;
}

/* But if the user's default font size (from browser text zoom setting or... */
/* user style sheet...) is larger than 32px, drop the columns. */
/* Old Note: the CSS MQ Level 3 syntax is (min-user-font-size: 32) */
/* Old Note: this example uses the greater-than/less-than syntax likely to be adopted by CSS MQ4. */
@media (user-font-size > 32) { 
    main {
        columns: auto;
    }
}

Other syntax ideas we've discussed include:

1. Reuse system-ui in other font contexts not limited to font-family.

font-size: system-ui;

2. Use a new keyword.

font-size: system-font-size; 

Incidentally a new keyword could be used in the shorthand as well:

font: system-font-size system-ui black;

And potentially as a font-size media feature:

@media (system-font-size > 32px) {
    /* Reduced layout from 2-column to 1-column, for example. */
}

3. Use a generic accessor of user preferences.
IIRC, Tab Atkins proposed something like this in 2015 or 2016.

font-size: user(font-size);
@media (user(font-size) > 32px) { }

…but env() is likely more practical now than the last example.

[clshortfuse]

Apple is actually following the specifications for system fonts as laid out in CSS Fonts Module Level 3

System fonts may only be set as a whole; that is, the font family, size, weight, style, etc. are all set at the same time. These values may then be altered individually if desired. If no font with the indicated characteristics exists on a given platform, the user agent should either intelligently substitute (e.g., a smaller version of the ‘caption’ font might be used for the ‘small-caption’ font), or substitute a user agent default font. As for regular fonts, if, for a system font, any of the individual properties are not part of the operating system's available user preferences, those properties should be set to their initial values.

https://drafts.csswg.org/css-fonts-3/#font-prop

The specification goes to list some examples of font values for system fonts:

  font: menu;        /* use the font settings for system menus */
  font: large menu;  /* use a font family named "menu" */

I didn't see anything exclusive whitelist to the names. I think the property needs a bit more attention.

As for the base font size, the reality is all major desktop browsers scale it based on user setings: Chrome, Safari, FireFox, Edge and Internet Explorer. They have done so for decades. It's mobile browsers (Safari, Chrome, and FireFox) that have locked up the HTML element to 16px and not something based on the system font-size. FireFox on Android actually lets you use "System Font Size" which allows rem to work properly. It's up to the user agent to provide the functionality.

Despite forcing 16px for the HTML element, Apple decided to still allow you to access the system font size (and type-face), but with an opt-in font CSS declaration. I'm not sure if more standards and newer options are the answer. (The media queries stuff does seem useful for other things though.) In reality, I would think it would be simpler to instruct the browser it doesn't need to break the standards we've already had in place since CSS2 (font-size:medium is the reference point that is usually 16px font.) Perhaps a meta tag in the head that instructs the browser to apply the same font standards as it would on desktop?

It's really about getting browsers to comply with the standards already in place. For example, W3 has already set a user-agent checkpoint for this in place back in 2002.

4.1 Configure text scale (P1)
Allow global configuration of the scale of visually rendered text content. Preserve distinctions in the size of rendered text as the user increases or decreases the scale.
As part of satisfying provision one of this checkpoint, provide a configuration option to override rendered text sizes specified by the author or user agent defaults.
As part of satisfying provision one of this checkpoint, offer a range of text sizes to the user that includes at least:

• the range offered by the conventional utility available in the operating environment that allows users to choose the text size (e.g., the font size), or
• if no such utility is available, the range of text sizes supported by the conventional APIs of the operating environment for drawing text.

https://www.w3.org/TR/WAI-USERAGENT/guidelines.html#tech-configure-text-scale

Apple has a workaround for this as stated and W3 included the workaround in their guidelines

https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Specifying_a_system_font_in_web_content_to_support_platform_text_resize_without_browser_or_platform_assistive_technology_zoom.

As for Chrome on Android, it fails. If Google can fix it moving forward, then I honestly don't see the need to create another standard. IMO, a standard font:-android-system-font would work fine and follows the W3 standards. If W3 wants to create a new declaration such as font:system that works for me too.

[tabatkins]

As @clshortfuse says, desktop browsers all respect the user's default font-size, and have for decades. Some pages break, but most are fine. Is the mobile web so substantially different in this regard?

(That said, if it turns out this is the case, my preferred solution is an env() value, not a system font. System fonts are big hammers and very awkward to use, particularly in cases like this where the only thing it's trying to communicate is a font size.)

[clshortfuse]

@tabatkins Getting the whole font has its uses though.

Most of the time, web authors will change the font, but there are situations where you want the website to look native (Electron Apps or PWAs). Then you sometimes don't want your dialogs, menus, or other component to look any different than system ones. I think that was the original intention of font back in CSS 2.1. The only problem is there was nothing states for body; there was only caption, icon, menu, message-box, small-caption and status-bar. There was no dedicated value for just the regular font. There's also the case that font-family has no specification. It's up to the user-agent. For example, Chrome on Mac OS X defaults to font-family:Times and not the system font. Nothing in the W3 spec says font-family should initialized as Times, and yet, here we are.

https://drafts.csswg.org/css-fonts-3/#propdef-font-family

At least we now have font-family: system-ui which is part of CSS Font-4. That formalized a solution and did away with people having to use font-family: -apple-system.

https://drafts.csswg.org/css-fonts-4/#valdef-font-family-system-ui

While font is a big sledgehammer to the problem, it can easily be reset back however you'd like. In fact, by using the Apple's proprietary value, you are subject to whatever Apple decides to change about the font in future. You should be overriding it anyway. You can easily override anything you don't want to be used in the next line after the declaration, like so:

html {
  font: system;
  /** Reset everything else **/
  font-style: initial;
  font-variant: initial;
  font-weight: initial;
  font-stretch: initial;
  /** font-size: initial; **/
  line-height: initial;
  font-family: initial;
}

Personally, I would override everything but font-size. There's also the case where the system font-variant may be useful. I think East-Asian languages have stronger benefit from this. Also if somebody wants to write a Web App (PWA) that would let somebody use that funky italic font on their Samsung if it's the system default, then they can. 😆

But just to reiterate, the current specification (in CSS Fonts 4) for font's value is :

[ [ <font-style> || <font-variant-css2> || <font-weight> || <font-stretch-css3> ]? <font-size> [ / <line-height> ]? <font-family> ] | caption | icon | menu | message-box | small-caption | status-bar

If it were:

[ [ <font-style> || <font-variant-css2> || <font-weight> || <font-stretch-css3> ]? <font-size> [ / <line-height> ]? <font-family> ] | caption | icon | menu | message-box | small-caption | status-bar | system

I'll be happy.

[cookiecrook]

@tabatkins wrote:

System fonts are big hammers and very awkward to use, particularly in cases like this where the only thing it's trying to communicate is a font size.

In addition the points above made by @clshortfuse, here's a specific example where this would be used for more than just font size. iOS has a system-wide setting to enable bold text*, which is reflected in the system weight. I don't have a preference for system-font versus env(), but all aspects should be ideally be retained.

@clshortfuse wrote:

html {
  font: system;
  font-weight: initial;
}

Aside FYI, resetting the user's preferred font weight may be an anti-pattern. Legally blind users and contrast-deficient users often enable this setting to increase text contrast to more perceivable levels.

[cookiecrook]

@tabatkins wrote:

As @clshortfuse says, desktop browsers all respect the user's default font-size, and have for decades. Some pages break, but most are fine.

I'd disagree that most are fine. Browsers all used to have an "enlarge text" method that most have abandoned because web sites implemented it so poorly. Now most browsers (including Safari) default to viewport zoom on the entire page, scaling images and block layout, too. The desktop viewport zoom you've mentioned ("most [sites] are fine") is directly equivalent to mobile viewport zoom, and so it's irrelevant to the font size discussion. This feature is already available on mobile via "pinch to zoom", "double-tap to zoom", and other ways.

Safari for Mac also retains a way to view the old "enlarge text only" behavior. Try it, and you'll see how much these CSS additions are needed. Either hold down "Option" while expanding the View menu, or use the hotkeys: Cmd+Opt+Shift+Plus/Minus.

When I enlarge the text to its largest size (rather than zooming the viewport), almost every site I tried had overlapping text and horribly broken layouts: Yahoo, New York Times, Gmail, ESPN, Netflix, Hulu, CNN, Wikipedia, Amazon, etc. They're all broken to the point that they are unreadable and unusable. Only one of the sites I tried, BBC, adjusted its layout reasonably, and it took a page refresh to get it right.

Even when web developers know about the problems, some layouts would not be possible to adjust properly, even with current techniques of responsive web design. For example, setting a block-level element's min-height and/or min-width to EM or REM units can get sometimes get you to a mediocre stop-gap solution, but it doesn't allow one to adjust complex layouts sufficiently.

Is the mobile web so substantially different in this regard?

Yes, substantially, because the viewports and screens are so much smaller than desktop displays.

Standard viewport zoom is already available to mobile users through "pinch to zoom" and other means. Mobile browsers could automatically zoom the viewport to match the user's preferred font size (as all desktop browsers do), but that would 1) cause excessive amounts of horizontal scrolling on mobile, and 2) provide absolutely no utility over existing methods of viewport zooming.

If mobile browsers applied extra large system font sizes to mobile, it would break the layout of almost all web sites. The experience would be so bad that users would have to turn off the feature entirely while using the web.

Native apps on mobile would similarly be broken if the large sizes were forced on them, so they aren't applied to apps automatically. App developers need to opt-in to supporting the larger font sizes. WWDC 2017 included a session on the iOS API called Building Apps with Dynamic Type.

[cookiecrook]

Footnote to this comment:

WWDC 2017 included a session on the iOS API called Building Apps with Dynamic Type.

Some of the layout changes discussed in that session would be impossible to achieve with current CSS techniques. At a minimum, the ability to reference user font size in a media query would be necessary to achieve some of the text size adaptation techniques that are used in native apps in iOS 10 and later.

[clshortfuse]

After closer analysis, there is nothing in the the actual W3C papers that state that the browser must be using the system font size as default. In fact, nothing says it has to be 16px either. medium is also just a starting reference point and that's up to the user-agent.

So, while desktop browsers applied the root element to use the system font size, that wasn't really part of the spec. Mobile browsers don't have to. But, because of that, applying W3C WAI's best practices for WCAG 1.4.4 becomes impossible on Chrome on Android without the authors creating their own custom text-scaling option just for Chrome.

https://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magnification

So I think this implementing this would really solve an accessibility issue that's been plaguing Android users for years now.

I don't know if I should open up another issue specifically targeting system font-size, or perhaps we can reach a consensus on the language of the issue. Perhaps we can rename the title?