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

@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 XXXL 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. 

```css
/* 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 a not font-family context.**
```css
font-size: system-ui;
```

2. Use a new keyword.
```css
font-size: system-font-size; 
```
Incidentally a new keyword could be used in the shorthand as well:
```css
font: system-font-size system-ui black;
```
And potentially as a font-size media feature:
```css
@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 a in 2015 or 2016.
```css
font-size: user(font-size);
@media (user(font-size) > 32px) { }
```

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



-- 
GitHub Notification of comment by cookiecrook
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3708#issuecomment-477403555 using your GitHub account

Received on Thursday, 28 March 2019 01:05:27 UTC