[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 seeing up a phone of my mom, 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?

[AmeliaBR]

Previous versions of CSS specifically required that “The 'medium' value is the user's preferred font size.” That requirement was somehow lost in the transition to CSS Fonts, and the WG in #2430 decided it wasn't important enough to add back in.

So, a first approach at addressing this issue could be to add that requirement back in, making it clear that the “user's preferred font size” should be taken from system preferences if the browser doesn't offer more direct control.

I personally think that's all that is required. Running through @cookiecrook's list of minimum needs, from above:

1. A way for authors to opt-in to the user's preferred font size. If authors can be confident that medium is the user's preferred font size, that's the way to do it.

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. Any website that uses absolute font sizes wouldn't change. (In contrast, if a website only uses relative font sizes but assumes the default will always be 16px, they will be broken already in many browsers.)

3. A way for authors to adapt their layouts to changes in the user's font-size. A media query that uses em or rem units (@media (min-width: 40em) {…}) would adapt based on the change in default font size.

[jonjohnjohnson]

@AmeliaBR 3. -> #2630 (comment)

[clshortfuse]

@AmeliaBR The user may prefer a certain size for their web-browser that may be different than system. For example, if you scale the font in Chrome on desktop to "Very Large" medium will change to 24px. AFAIK, Mac OS X doesn't let you just scale text like you can on iOS or Windows. This makes me believe that there are many that have different browser (user-agent) preferred size than the system one.

It doesn't solve the issue that Chrome on mobile doesn't allow you change the user's specified font-size. Also, for PWAs that want to look "native", you might still want the system font-size (or even style). You can accomplish this with -apple-system-body, but that's not part of any spec and it is Mac/iOS exclusive.

[AmeliaBR]

that's not part of any spec

System fonts that include font size are part of the spec for the font shorthand property. The -apple-system-* font keywords are unique because they map to a font family without specifying a font size or bold/italic etc. (See corrections in following comments)

Chrome on mobile doesn't allow you change the user's specified font-size.

Which is a limitation of the browser UI, not a limitation of the spec.

[clshortfuse]

@AmeliaBR

System fonts that include font size are part of the spec for the font shorthand property. The -apple-system-* font keywords are unique because they map to a font family without specifying a font size or bold/italic etc.

Unless I'm misunderstanding your comment, -apple-system-body does change the font-size. That's really the way Dynamic Type works. You set it in iOS settings and then any Safari page that uses that font property will get all the font styles. I explained this a bit better in a previous. #3708 (comment)

This Webkit blog entry states:

These text styles identify more than simply a particular font family; instead, they represent an entire style, including size and weight.

@cookiecrook Also made a great point that an OS can have system-wide bold/italic setting:

iOS has a system-wide setting to enable bold text*, which is reflected in the system weight.

That's why I'm advocating for font: system which would have more benefits. That's also why I was unsure if I should open up another issue that is specifically targeting the entire system font, versus just the font-size.

Which is a limitation of the browser UI, not a limitation of the spec.

The problem is, there's no spec for how and when to use the default system font size, so any implementation of it would be custom. I came across this issue because I directed here by the Chromium team.

https://bugs.chromium.org/p/chromium/issues/detail?id=942045#c17

Which basically translates, if this is added to spec, then it can be added to Chrome. And I fully understand the team's position, being that it's better to see if W3C can reach a consensus how it can be implemented, and then implement it into the browser. I'm assuming they want to avoid adding something proprietary like Apple did.

[AmeliaBR]

@clshortfuse Apologies, I was clearly confusing the apple system font keyword with the font family keywords used on other systems like Android. So, font: -apple-system-body does work the same as font: caption and the other shorthand keywords. That's definitely something that could be standardized, if there's demand for it.

For reference, the current shorthand font keywords in the spec are:

caption

The font used for captioned controls (e.g., buttons, drop-downs, etc.).

icon

The font used to label icons.

menu

The font used in menus (e.g., dropdown menus and menu lists).

message-box

The font used in dialog boxes.

small-caption

The font used for labeling small controls.

status-bar

The font used in window status bars.

So they're focused on form elements, but don't cover general text content. Adding a system-body or body-text keyword does make sense.

But I don't see how that addresses the general problem of setting font-size according to the user preference, without an OS-themed font family. Are you suggesting that authors use font: system; font-family: my-web-font;, to indirectly set the font size & then reset it? Or are you suggesting that separate mechanisms are required?

[AmeliaBR]

if this is added to spec, then it can be added to Chrome

If I'm reading that issue correctly, it would be addressed by my recommendation above, to reinstate the requirement that the default/medium font-size must match user preferences, with an added clarification that an OS-level preference should be used unless the browser offers its own preference mechanism.

But it sounds like you want the spec to go a step further, and state that user agents should provide their own direct user control for the default font-size? I wouldn't mind that, but given the response to the last discussion about this (#2430), I'm not sure that the group would agree.

[clshortfuse]

@AmeliaBR Yes, I covered it a bit in this comment. You can also set font-family: initial if you want to keep the browser default. That's actually how cookiecrook caught on that, for accessibility purposes, we shouldn't be resetting font-weight .

But now that I read what you were saying about medium and thinking it over, that wouldn't solve another issue. Mac OS X has no resizing of system font. Even if the user scales up their text in the browser (uses "Very Large"), then font:system should still set it to the whatever Mac OS X uses (San Francisco @ 16px). You may want that for "web apps", but probably not websites. It would work on iOS, Android, and Windows because those operating systems allow font scaling. Unless, we say that font:system can only be implemented on OS's with font-scaling support (most except Mac OS X). But even that gets messy.

That means effectively, we will still need another property for the size itself. I do like font-size:medium, personally, but I think most resistance you'll find is existing content would change. People have, perhaps, already built styles expecting font-size:medium to be 16px on Chrome Mobile and iOS (assuming they're not using Dynamic Type). That means, we unfortunately need a new property, (eg: font-size:preferred or font-size: env(user-font-size)).

Regardless, the property in question should be SYSTEM_FONT_SIZE * BROWSER_FONT_SCALE. On iOS and Android, BROWSER_FONT_SIZE would likely always be 100% with SYSTEM_FONT_SIZE being variable. But on Mac OS X, it would be the opposite. Windows would likely support both. So now I'm envisioning:

html {
  /* iOS Dynamic Type */
  font: -apple-system-body;
  /* New CSS Spec to get system font-family and system font-weight */
  font: system;
  /* New CSS Spec to get preferred font size Option 1 */
  font-size: preferred;
  /* New CSS Spec to get preferred font size Option 2 */
  font-size: env(user-font-size);
  /* Fallback to get system font-family */
  font-family: system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif;
}

Which would cover a native-like experience (for PWAs or Electron), allow font-scaling on browsers that support it, while providing a fallback for those that don't. (Style authors can always change font-family).

[css-meeting-bot]

The CSS Working Group just discussed Dynamic text size.

The full IRC log of that discussion

<TabAtkins> Topic: Dynamic text size
<astearns> github: https://github.com//issues/3708
<TabAtkins> AmeliaBR: Want to bea ble to respect user's font sizes, espeically on mobile, without arbitrarily overriding website styles in ways that break pages
<TabAtkins> AmeliaBR: Want good pages to be able to opt into user's prefs at the OS level.
<TabAtkins> AmeliaBR: I brought it up becaus ein the issue' slong discussion there were some straightforward proposals.
<TabAtkins> AmeliaBR: One was a new "system-font" keyword (for 'font' shorthand)
<TabAtkins> AmeliaBR: WebKit has a keyword for that
<TabAtkins> AmeliaBR: Suggestino is to standardize that
<TabAtkins> AmeliaBR: Already have font-family keyword that is system-ui, waiting for FF impl, but in two browsers and in spec
<TabAtkins> AmeliaBR: Diff for 'font' keyword is you'd also get defautl sizing
<TabAtkins> AmeliaBR: Second, trickier aspect is what if an author wants to opt into the user's font size without getting the system font.
<TabAtkins> AmeliaBR: My argument is taht's what "medium" was supposed to be.
<TabAtkins> AmeliaBR: Might get messy, maybe we can talk about that.
<TabAtkins> myles_: Some context:
<TabAtkins> myles_: browsers have 11k ways to adjust text sizes
<TabAtkins> myles_: All area balance between making text readable and trying to not break layout
<TabAtkins> myles_: Having a website opt in and say "I know this part of the page will respond well" won't fix every site, but will at least let us resize taht part more freely.
<TabAtkins> myles_: General request is really important for a11y.
<TabAtkins> myles_: (and just that people like to change their font size)
<TabAtkins> myles_: Every OS has this, ebook readers too.
<TabAtkins> myles_: So I'm just hoping for some way for a website to say "for this part of the page, go hogwild"
<TabAtkins> myles_: We have a non-standard prefixed mechanism for this
<TabAtkins> myles_: Would be cool to resolve on that, but we're not married to it
<TabAtkins> myles_: ANother idea is to use env()
<TabAtkins> myles_: Interesting on iOS which lets you change both size *and* weight
<TabAtkins> myles_: I don't wanna prescribe any specific solutions, but would be cool to come up with something for this.
<AmeliaBR> s/talk about that/talk about that after agreeing on the shorthand keyword/
<TabAtkins> myles_: OUr existing solution is a 'font' keyword
<TabAtkins> myles_: You can say "font: -apple-system-body"
<AmeliaBR> Proposal is to add a `system-body` keyword for the font shorthand. Sets the font-family and size together.
<TabAtkins> myles_: It'll resolve to a specific size, so if you want your page to react fluidly as the user slides their font-size slider, you put that value on the root element and let the inherited style work correctly
<TabAtkins> koji: I don't have a preference for solution, but I'm hearing the request for -apple-system-body in Blink
<TabAtkins> koji: Would be great to standardize
<TabAtkins> dbaron: Presumably there's some default size for this keyword.
<TabAtkins> dbaron: What % of users have it at this default size?
<TabAtkins> dbaron: My concern is that if it's over, say, 75% or more, pages will likely still not work if it changes.
<TabAtkins> myles_: Dunno
<chris> q+
<TabAtkins> AmeliaBR: The whole point of this is to not change anything by default
<TabAtkins> AmeliaBR: Webpages have to opt into it
<TabAtkins> AmeliaBR: So your concern is that they might opt in thinkiing they're getting a standared default, and not realize it's adjustable?
<TabAtkins> dbaron: My concern is that things that don't get tested get broken. If it's only true for a small %, it won't get tested, and even if original design got it right, someone will come along later and make it break for a non-default size.
<TabAtkins> dbaron: Just like before we made px be a 96:1 ratio with in. Users with a different ratio, only in Firefox and IE, saw broken websites.
<TabAtkins> myles_: Can't answer directly, but can offer some info
<TabAtkins> myles_: In our xp, this isn't just a11y. Many users change just because they like bigger text sizes
<dbaron> TabAtkins: it sounds like from your suggestion from using -apple--ystem-body on the root and then using rems or inheritance
<dbaron> ... does address Amelia's request to just get the font size people want?
<dbaron> myles_: yes
<dbaron> TabAtkins: it sounds like from your response to david that there's a decent percentagechanging to a non-default value?
<dbaron> myles_: yes
<TabAtkins> jensimmons: Is what's being proposed only affecting font-size? Or is there an easy way to cascade that measurement into layout?
<TabAtkins> jensimmons: Is it diff from just using 'em's, etc?
<astearns> q+
<TabAtkins> myles_: This should be a way of seting font-size like any other way of doing so. Does that answer your question?
<AmeliaBR> s/--ystem/-system/
<TabAtkins> jensimmons: There are many websites that don't do things right, we have to consider them bc they're majority. But this is an issue been incredeibly important to front-end designers/teachers: make a webpage work when people choose their font size.
<TabAtkins> jensimmons: These days the only thing left ot understnad is how to zoom on desktop
<TabAtkins> jensimmons: Be3st practice has change dmany times over the years.
<TabAtkins> jensimmons: A bit of tail-chasing, browsers trying to chase badly-writtens ites, and good sites chasing browsers, and round and round.
<TabAtkins> jensimmons: And bc info about best practice ages, people dont' realize it's old; like people still say "set font-size on root to 10px and use 'rem'"
<TabAtkins> jensimmons: So this comes down to, have an easy way to let users change font size and have an easy way to adapt to it.
<TabAtkins> jensimmons: So I just want this to fit into that evolutionary convo.
<TabAtkins> jensimmons: Rather than YetAnotherWayToDoIt
<TabAtkins> (YAWTDI)
<TabAtkins> myles_: agree 100%
<TabAtkins> myles_: My intention isn't to make a new blessed way to design responsive websites
<florian> q?
<florian> q+
<florian> q-
<TabAtkins> myles_: More allow authors to annotate their source with some info we don't already have, and that annotation is "this part of the page works well when font-size changes"
<TabAtkins> florian: I think this new proposal ahs a chance of breaking the cycle, precisely because this setting is used by a large number of people. It's always existed, but tended to b eused by few.
<jensimmons> q?
<TabAtkins> florian: Like dbaron said, when too few people use it, things break.
<TabAtkins> florian: But because this is used by many, there's a chance it'll stay viable, rather than being poisoned by maintenance.
<TabAtkins> jensimmons: THe idea we should take the pref setting and give it to webdevs to use, I'm definitely for it.
<astearns> ack chris
<heycam> q+ to ask why is this -apply-system-body font size not the default font size applied in the page?
<TabAtkins> chris: I noticed in the thread that someone suggested there should be a property that is system-font-size * browser font scale
<jensimmons> heycam: +1
<TabAtkins> chris: I'm not opposed to a new generic font family, but if people are using that purely to get at the size, that seems more robust to me.
<chris> "the property in question should be SYSTEM_FONT_SIZE * BROWSER_FONT_SCALE. On iOS and Android, BROWSER_FONT_SIZE would likely always be 100% with SYSTEM_FONT_SIZE being variable. But on Mac OS X, it would be the opposite. Windows would likely support both. "
<TabAtkins> chris: To get the size directyl, rather than usign the whole font just to get the size
<jensimmons> (I mean +1 to what heycam added to the question que… not that he said “+1”)
<TabAtkins> AmeliaBR: There's content out now that's UA-dependent, trying to recreate the system body font.
<TabAtkins> AmeliaBR: (which I find annoying, as I don't like Window's system font...)
<TabAtkins> AmeliaBR: But a keyword would b esmarter than the website trying to *guess* that I want Seguo UI.
<TabAtkins> AmeliaBR: So I think there's a demand for combined, but we should also do apart. But Tab did say that if we have the font keyword on root, we can just use 'rem's.
<TabAtkins> AmeliaBR: But I would prefer "font-size: medium" to do actually that, but...
<TabAtkins> chris: You ran some tests; we saw that browser didn't do that.
<TabAtkins> myles_: WE've tried to make "medium" reflect preferred size. It breaks too much, can't do it.
<TabAtkins> astearns: Why is this a keyword on 'font' rather than a keyword for font-size?
<TabAtkins> myles_: There's a collection of 'font' keywords.
<TabAtkins> myles_: This one means "this is the size that best fits apple body text"
<TabAtkins> myles_: Now that we have system-ui generic font family distinct from that, I think the use-case is [...?]
<TabAtkins> astearns: So system-ui is on font-family, not 'font'?
<TabAtkins> myles_: Yes.
<astearns> ack astearns
<jensimmons> q+
<chris> so I guess it sets the line spacing too
<astearns> ack heycam
<Zakim> heycam, you wanted to ask why is this -apply-system-body font size not the default font size applied in the page?
<TabAtkins> heycam: You answered "Why is this just not the default". What specifically did you try? Did you try switching "medium" and leaving th einitial font-size to 16px, di dyou try changing initial and leaving "medium", or?
<TabAtkins> myles_: The latter
<TabAtkins> heycam: What actual font-family is set by this? Same initial value that kinda depends on lang and so on? Or always serif?
<TabAtkins> myles_: The system font, "San Francisco" on Apple
<TabAtkins> TabAtkins: So it's the system-ui font?
<TabAtkins> myles_: Yes
<astearns> ack jensimmons
<TabAtkins> AmeliaBR: system-ui is a new generic, an alternative to 'serif' or 'sans-serif'
<TabAtkins> jensimmons: If your CSS you use to react to diff prefs is different on mobile than desktop, that's bad. Is it?
<TabAtkins> myles_: Android and iOS both have this setting, windows desktop has this setting. Dont think it would differ.
<TabAtkins> jensimmons: [minuting failure]
<TabAtkins> jensimmons: If this is something you're supposed to use, but it only works in some browsers, that's a problem.
<TabAtkins> AmeliaBR: So your concern is that browsers with an in-browser font-size option, the system font being pulled from outside the browser wouldn't match?
<TabAtkins> myles_: Does "work" mean that it draws from the OS? That can be done on eveyr platform. Or does it mean some devices on a platform will have one value and other devices on that platform will have others?
<TabAtkins> AmeliaBR: So should the value come from browser, or browser+OS, or what?
<TabAtkins> TabAtkins: I don't think there's any reasonabl euse-case for "OS size" different from "browser-provided default size"
<TabAtkins> chris: I wasn't suggesting two vars, I was suggesting a single thing from multiplying those together.
<TabAtkins> myles_: So I think we have consensus for a font-size env()?
<TabAtkins> myles_: Also, since we expose weight, do we want an env() for weight?
<TabAtkins> TabAtkins: Sounds okay, but slightly concerned due to dbaron's concern about small usage.
<AmeliaBR> So, to get the effect of the -apple-system-body keyword would be `font: env(preferred-font-size) system-ui;`
<TabAtkins> emilio: Firefox's font settings are per-lang, so I'm not sure how to distill that to an env() value
<TabAtkins> And to get the opposite would be `font: -apple-system-body; font-family: foo;`
<TabAtkins> astearns: I don't like the default weight; the page would lose the the distinction between bold and not.
<TabAtkins> myles_: Yeah, they're aksing for that.
<TabAtkins> astearns: They're asking for it in system UI, which doesn't use much bold. Not necessarily in web content.
<TabAtkins> TabAtkins: Does Apple system ui tend to use bold to distinguish stuff, such that the default weight would lose information?
<TabAtkins> myles_: There's some, but it's rare, so not much info is lost.
<TabAtkins> astearns: So emilio, if you had an env(), you'd have to pick which size to use based on lang, etc.
<TabAtkins> astearns: But you have to make the same decision for the keyword, right?
<TabAtkins> emilio: Different. You'd have the element language, you'd apply the generic family.
<TabAtkins> TabAtkins: So you're saying that the font keyword, being resolved on the element, can be different per-element based on lang? But the env(), which should be global, can't do that?
<TabAtkins> emilio: Yes.
<TabAtkins> AmeliaBR: "medium" on Chrome and Firefox currently resolves to user font size.
<koji> q+
<TabAtkins> emilio: Right, so I guess an env() font-size for that would be okay.
<astearns> ack koji
<TabAtkins> koji: I'm confused. THi sis about exposign system font size setting, right?
<dbaron> s/right/not user's setting in browsers, right/
<TabAtkins> koji: But windows/mac/etc all expose only a single value
<dbaron> emilio: That makes sense.
<TabAtkins> AmeliaBR: The idea is that the exposed variable is the setting in the browser, if they capture that, or OS otherwise
<TabAtkins> fantasai: A problem with "medium" is that it can't reflect user setting
<TabAtkins> TabAtkins: Myles did tests for the *initial value* being user's setting, and that broke stuff. But Chrome/Firefox reflect "medium" being the user's setting.
<TabAtkins> AmeliaBR: But that's the same thing, as "medium" is the initial value.
<TabAtkins> myles_: So I think this topic is an investigation, we're not going to finish right now.
<TabAtkins> astearns: But I think the room has a general intent that this is a good idea.
<TabAtkins> AmeliaBR: If people have data for what % of users change their default font size, or how much breakage is observed when things change, this would be useful info in the issue.

[litherum]

In summary, the conclusion of the conversation today:

• There needs to be a coherent story for web developers to make a scalable site. There are currently some set of best practices, and these have dramatically changed over time, and the web community should try to settle on a single recommendation.
• There are two competing proposals:
  • font: system-body Because this is a shorthand, it sets all the font properties to their OS-provided values. Inheritance works properly, so authors can scale their content by using ems and rems. Setting all the font properties and then immediately overwriting font-family (so just the other properties remain) seems yucky.
  • env(font-size-multiplier) Only exposes a single scalar, so an extra variable is needed for the OS-provided weight. Can be used in any element using calc().
• Chrome and Firefox map font-size: medium to the user's preferred font size. The spec used to dictate this, but it no longer says that. Compat data would be valuable.

We didn't talk about a media query or a way to switch to a new layout.

[fantasai]

It was also pointed out that Firefox's default font size for web pages varies by language and generic font family, so length value (or a multiplier intended to be multiplied by 16px? which is what I'm guessing env(font-size-multiplier) is supposed to be) cannot represent the user-preferred defaults.

More generically, the font used in system dialogs and the user's preferred text size for long form content (such as web content) might not be identical: which one are we trying to represent here, and is that really what we want?

[kojiishi]

Thank you for the clarification, at some point I was confused which one we were talking about. What I'm interested in is the font used in system dialogs. Firefox for Android has "Use system font size" option in its Accessibility settings, but authors can't enable it. Safari is the only mobile browser that allows web authors to create such pages today with --apple-system-body. An interoperable way to create such pages would be great.

[fantasai]

Reading through the F2F minutes, it was asserted that there's a compat problem with making the initial value be other than 16px, but it wasn't clear whether mapping the 'medium' keyword to the user's preferred font size was also problematic. (The initial value is currently specced to be 'medium', but this could be decoupled.)

[css-meeting-bot]

The CSS Working Group just discussed Dynamic text size, and agreed to the following:

• RESOLVED: There should be a way to have true font sizes.

The full IRC log of that discussion

<mstange> Topic: Dynamic text size
<heycam> github: https://github.com//issues/3708
<mstange> ???: For a long time we've had scalable fonts that are based on the Desktop Web.
<heycam> s/???/jcraig/
<mstange> jcraig: It took us a while to make it work on all extreme cases.
<mstange> ... We would like to support low vision users who have extremely large text sizes.
<mstange> ... Forcing such giant font sizes on web pages would make most web pages unreadable.
<mstange> ... We would like to have a way to opt in to larger font sizes.
<mstange> ... as an author.
<mstange> ... We would also like to propose a feature that allows web pages to detect large font sizes and adjust the sizes of other elements.
<mstange> ... We have some aspects of this that are available today: You could detect based on min-width in ems, but that does not work consistently.
<mstange> ... Right now there is no standard way to opt in to this that works across all browsers.
<mstange> ... Most browsers on mobile systems don't want to break their users' layout.
<mstange> ... We have examples where it would be very difficult or even impossible to achieve the intended layouts today.
<mstange> jcraig: [demo]
<mstange> ... I have applied iOS settings that render text extremely large and bold.
<mstange> ... I can show how different apps deal with this setting.
<mstange> ... Calendar switches to 3 or 2 column layouts.
<mstange> ... The Books app switches from a 2 column layout to a single column layout.
<fantasai> These are all very easy to do if you have flexbox/grid and correctly implement media queries in em units
<fantasai> or ch units
<mstange> ... In Mail, with larger font sizes, the title gets clipped but the email's time is preserved.
<mstange> fantasai: Is the problem that we can't actually implement media queries with em and ch units because the web would break, but you want to have media queries with em and ch units?
<mstange> ... Everything you've demonstrated here is totally possible with em and ch units in media queries.
<mstange> ... On mobile you're not returning the correct values because that would break. So what you're saying is you want real units?
<mstange> jcraig: What we want is an ability for an author to say "I can handle any font size you throw at me."
<mstange> florian: How possible is that this signal becomes worthless over time as it gets copied around, and we need to add still another signal?
<mstange> chris: People are rapidly going to find out that just copying this around will break them.
<mstange> jcraig: The reason we don't turn this on by default is that web developers *don't* find out that it breaks them.
<mstange> ... They haven't turned on these large fonts on their system.
<chris> fair point, retracted
<mstange> jcraig: The first part of what we need is the opt in to the higher font sizes. The second part is the media query part.
<mstange> fantasai: In order to do the kind of layout transformations you want, you also have to know how many letters fit on the screen. You'd use the min-width query.
<mstange> jcraig: That would get us some of the way.
<mstange> fantasai: Having just the media query for the font size is not enough if you can't relate it to the size of the viewport.
<mstange> florian: You can't compare the font size and the viewport because the lengths have different units.
<mstange> ... The thing you call an opt in would also opt in the media queries to behave properly.
<mstange> ... Whichever opt-in we have needs to opt in both to behave how things were originally intended.
<AmeliaBR> `@media (min-height: 10em)` only works if the window root em size is accurate. So if we don't reveal the accurate preferred em value except in an environment value, you'd need to use `@media (min-height: calc(10*env(user-font-size)) )`
<mstange> ???: If you have a user font size variable, you can use calc to obtain the right answer.
<heycam> s/???/fremy/
<mstange> fantasai: As an environment variable, it would work out.
<mstange> ... But (?) it would be multiple variables, not one variable.
<mstange> fantasai: The size of ch is dependent on the initial font, not on the font that is used.
<mstange> florian: There is a number of ways you can use environment variables to do what you want, but if the opt-in mechanism opted in everything, it would also work.
<AmeliaBR> s/(?)/Firefox uses different font-sizes for different languages, so/
<mstange> florian: Is there reason to exclude media queries from the opt in?
<mstange> jcraig: It should not be excluded.
<mstange> fremy: You want to be able to opt in only parts of a web site.
<mstange> ... If the developer in the iframe did the work to deal with large fonts, if it is embedded in another website that does not handle them, all the work is for nothing.
<mstange> jcraig: The reverse is also true.
<mstange> fantasai: If the widget is inheriting the font from the parent document, then it's going to have problems if the parent document picks a larger font, regardless.
<mstange> fremy: You cannot say media queries behave differently for different parts of the same document.
<mstange> florian: Yes, if you put a responsive widget into a non-responsive website, then yes, your responsiveness is wasted.
<mstange> jcraig: It sounds like we're agreeing that it would be useful to have an opt-in for websites to express that they can handle large font sizes.
<mstange> florian: And we do not agree on the media query part - depending on how we do the opt-in switch, that switch may also opt in media queries automatically.
<mstange> florian: If we can't make the existing media queries work, we maybe need to add more media queries.
<mstange> jcraig: That sounds reasonable. Once we have an opt-in we can experiment and see in what cases it's not good enough.
<mstange> AmeliaBR: Having it in CSS would be better than having it in markup because you can put it into one shared stylesheet.
<mstange> ... In order to get useful media queries, the opt in has to be outside of a property.
<mstange> ... If somebody has explicitly set this opt in value, then the existing font-size keywords that were supposed to be relative to the user-chosen default font size can actually do that.
<plinss> q+
<mstange> ... Otherwise, the default size will be the legacy 16px.
<mstange> jcraig: I think that sounds ok. But a new media query would be clearer in terms of what we want to communicate to authors.
<mstange> ... Without that, the complexity of doing layouts based on width and layouts based on font-size is going to result in lots of media query blocks. (?)
<mstange> Rossen_: We need to work towards a resolution.
<Rossen_> q?
<Rossen_> ack plh
<Rossen_> ack plinss
<Rossen_> ack fantasai
<jcraig> Q+
<mstange> plinss: I'm concerned about adding yet another mode switch. Mode switches are bad. Can we do the right thing without a switch?
<mstange> fantasai: I hate meta tags because you can't put them in a stylesheet and link them from everywhere.
<mstange> ... However, it seems to make the most sense to add this as a meta tag because it affects media queries and the initial containing block size.
<gsnedders> RRSAgent: make the minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html gsnedders
<mstange> ... And once the mode has been switched, font sizes and everything else can start working the way initially intended.
<florian> q+?
<mstange> ... These things all belong together so we should just tack on a meta tag.
<mstange> Rossen_: I do not hear agreement on exact technicalities.
<mstange> Rossen_: Let's have a resolution on having a way to opt in, even if we don't have the exact way of doing it.
<mstange> Rossen_: Objections on opting in to true user font sizes?
<mstange> jcraig: We (Apple) tried to do this without a mode switch, by default, and all 200 000 apps broke.
<mstange> ... Even with an opt-in switch, it took years for all first party apps to support this mode.
<mstange> fantasai: I don't like mode switches either, but the alternative is to add an entire set of units. A mode switch is a lot simpler.
<mstange> AmeliaBR: I came in with the same concerns as plinss, but one thing I did bring up was that, at the user agent level, there should be reflection of the fact that there are two cclasses of users.
<mstange> ... Some users want fonts that don't want broken web pages, and some users want readable fonts even if pages are broken.
<mstange> ... It seems that most users will accept smaller fonts if it means that pages are not broken.
<mstange> plinss: I have no concerns with a user switch. I have concerns with adding a switch to the web platform.
<mstange> ... If we have to commit the sin again of adding another mode switch, let's add it in a way that it can fade away in the future, and not such that content will break if authors don't anticipate the switch.
<mstange> ... There is real costs to adding mode switches.
<mstange> myles: The resolution seems to be about intention, not implementation. Let's try to agree on that.
<mstange> Rossen_: Objections to having the option to have two font sizes?
<fantasai> s/two/true/
<mstange> RESOLVED: There should be a way to have true font sizes.
<karl> RRSAgent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html karl
<emilio> cmp: https://bugzilla.mozilla.org/show_bug.cgi?id=1252821

[cookiecrook]

Resolution from the F2F was to have a an opt-in switch for the web authors to get the true user font size, even on small screen device... Ideally the opt-in could be phased out over time if/when the Web handled scalability better.

General consensus was that this should be an addition to <meta viewport>

[svgeesus]

removing css-fonts-5 labe as consensus was to express this via <meta viewport>

[AmeliaBR]

We may still want some clarifying notes added to CSS Fonts. But first we need to spec the new <meta name="viewport"> option. @litherum, I think that one's on you. Especially since there doesn't seem to be any standard documentation for the viewport meta tag beyond Apple's docs, anyway. (See whatwg/html#3494 and whatwg/html#4561 for discussion about getting that into HTML.)

[cookiecrook]

Closing the loop on this. Since the discussions last Fall, iOS Safari has shipped a per-site font size setting, so my understanding is that we no longer need an author opt-in.

[chrislachance]

There is a way to use system font settings on iOS WITHOUT a per-site-user-manually-sets-each-time setting. - See csstools/sanitize.css#219 and https://codepen.io/chrislachance/pen/OJpmgrM

[clshortfuse]

Closing the loop on this. Since the discussions last Fall, iOS Safari has shipped a per-site font size setting, so my understanding is that we no longer need an author opt-in.

@cookiecrook It's great that Apple has something, as well as a workaround. But Android is still forced to 16px. I can easily change zoom (page scaling) with the meta viewport (and I do). But PWAs on iOS devices use whatever the system text size is. PWAs installed over Chrome will always use 16px font, regardless of what the system font size is. In practical experience, the concern is the PWAs I write have font size much smaller than users' other apps.

I pester because Chrome team won't move forward on this unless there's a specification (whereas Apple made a proprietary font-size value).

Edit: Sorry, I noticed @litherum closed this. Can we can get an explanation, or some direction as to where to go to help get this implemented?

[cookiecrook]

@clshortfuse wrote:

I pester because Chrome team won't move forward on this unless there's a specification (whereas Apple made a proprietary font-size value).

The end solution was not the old -apple-system value, which is not widely used.

The solution was that Safari added a site-specific font size control that adjusts the font for any web text, regardless of how the author specifies the units.

But Android is still forced to 16px.

Any browser can add a font size controller to the UI. No additional spec work needed.

[cookiecrook]

@chrislachance wrote:

There is a way to use system font settings on iOS WITHOUT a per-site-user-manually-sets-each-time setting

To clarify, it's not "each time" but "once per site/domain" which turns out to be much more usable than increasing the font size for every site or app...

Most web sites (and even some native iOS apps) are not coded to render well with extra large text, so the native setting can now be applied on an app-by-app basis. This is better received because users don't have to reduce their system font size just to use one poorly coded app.

Likewise, Safari's site-specific control allows low vision users to set the most comfortable font size that works on that site, without worrying about breaking Safari's rendering of the rest of the Web.

[clshortfuse]

The solution was that Safari added a site-specific font size control that adjusts the font for any web text, regardless of how the author specifies the units.

That doesn't work on PWAs though. Personally, I only write Web Apps (PWAs) for businesses so nothing the "full browser" experience provides helps. So you still have to use -apple-system-body if you want proper accessibility support in Web Apps. Right now I'm using that for my users that need larger fonts. The moment the Web App opens, it's automatic and there's nothing more needed.

As for those on Android, I modify the font-size on <html>. It has to be configure manually, and I've even had to add the ability to remotely configure the user's font-size because forcing them to navigating at 16px font-size to enable said options in a custom UI was too stressful for some users.

[cookiecrook]

That doesn't work on PWAs though.

I don’t think that’s a CSS problem. Any browser (including a PWA wrapper web view) can add a font size controller.