W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2019

Re: [csswg-drafts] [css-fonts-5] Dynamic text size (#3708)

From: Carlos Lopez via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 Mar 2019 03:31:08 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-477433666-1553743867-sysbot+gh@w3.org>
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.


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.


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


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.

GitHub Notification of comment by clshortfuse
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3708#issuecomment-477433666 using your GitHub account
Received on Thursday, 28 March 2019 03:31:10 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:45 UTC