[css-fonts] font-size: 'medium' value is the user's preferred font size

[TalbotG]

CSS2.1 and CSS2.2 have this sentence:

"
The 'medium' value is the user's preferred font size and is used as the reference middle value.
"

15.7 Font size: the 'font-size' property
https://www.w3.org/TR/CSS21/fonts.html#font-size-props
https://www.w3.org/TR/CSS22/fonts.html#font-size-props

I am convinced that a lot of web authors do not know this.

Now, in CSS3 and CSS4, such sentence was removed:

https://www.w3.org/TR/css-fonts-3/#font-size-prop

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

https://www.w3.org/TR/css-fonts-4/#font-size-prop

I think it should be reinstated.

[svgeesus]

If most people don't know, or don't take into account, or browsers don't implement, the concept that medium was supposed to be the user's preferred font size, then it was correct to remove it in Fonts 3. So, why reinstate it?

[TalbotG]

Chris,

If a wide majority of web authors don't know or don't take into account that 'medium' value is the user's preferred font size, then removing such statement will not improve their knowledge or competence and the opportunity to do so will be removed. A wide majority of ordinary web authors think and believe that CSS specifications are too technical. Such 9 words statement is not a burden.

As a web author, I do not know and can not know what are each of my visitors' preferred font size and it is impossible to match all of them simultaneously by choosing one absolute value (example given: say, 16px: which can be too small for some and too big for others). But what if I could match all of my visitors' individual preference setting in their browser for each of the platforms (mobile, tablet, laptop, desktop) they use with the screen resolution they have or choose, then we all win.

Why reinstate it?
1- for accessibility reasons
2- browsers implement it (MS-Edge offers only 4 predefined values for medium; IE11 offers 5 predefined values for medium; iPhone and iPad offers 7 predefined values; Firefox and Chrome offer full customization)
3- one arbitrary (font) size can not satisfy, can not suit everyone's viewing/reading abilities
4- web accessibility advocady groups or individuals refer to it implicitly or explicitly, directly or indirectly
5- other documents (Voluntary Product Accessibility Template, browser documentation, website support pages, WCAG) refer to it implicitly or explicitly, directly or indirectly

[AmeliaBR]

If most people don't know, or don't take into account, or browsers don't implement, the concept that medium was supposed to be the user's preferred font size, then it was correct to remove it in Fonts 3. So, why reinstate it?

For me, the first question is: do browser's implement it this way? That is, do they adjust the actual value of font-size: medium text to match the user's preferred setting, or do they match it to an absolute value? If so, it's up to the specs to make sure that web authors know about it.

Based on my test (Codepen):

• Chrome and Firefox do adjust medium to match the preferred font-size. (Which is slightly confusing in Chrome because their preferred font-size dialog itself uses small/medium/large/etc keywords as options, but that's a minor quibble compared to the usefulness of this feature!)

• As far as I can tell, MS Edge and Safari don't have any option, in the browser or OS level, to set a user preferred font-size.

So with two rendering engines implementing this behavior, and the other two not contradicting it, I'd say this relationship should be (once again) made explicit in the specs.

As part of that, I'd recommend reconsidering the terminology that these are "absolute size" keywords. They are absolute in the scope of a document (I.e., they aren't affected by inheritance), but they are not absolute in the same way that lengths are absolute.

[TalbotG]

Chrome (...) their preferred font-size dialog itself uses small/medium/large/etc keywords as options

As an user, you can then set, customize to whatever value you prefer in pixels what is the font-size of medium value in Chrome. In Appearence section, below "Font size", there is "Customize fonts" where you can set medium value to whatever value you prefer in pixels.

MS Edge and Safari don't have any option, in the browser or OS level, to set a user preferred font-size.

In IE11, there is a Text size setting (from the menu bar, View and then Text Size; or from the command bar: Page and then Text Size) with 5 predefined values: Smallest, Smaller, Medium, Larger and Largest. Medium value is default setting and is preset at 16px.

[TalbotG]

According to this video (duration: 31sec)
How to change default font size in Edge web browser
the user can only choose among 4 preset (small, medium, large, extra-large) values for her/his default font size and she/he can not customize her/his preference in pixels for the medium value (presumably preset at 16px).

In Konqueror, the user can set, customize the value she/he prefers in pixels for the medium value and then see how it looks, how big the glyphs are with a preset sentence ("The brown fox jumps over the lazy dog.").

I believe the user can set, customize the value she/he prefers in pixels for the medium value also in less common browsers and web-aware browsers (iCab, AntennaHouse, Prince, etc.).

[TalbotG]

Safari don't have any option, in the browser or OS level, to set a user preferred font-size.

According to fig 2 and fig 3 of
How to make the text larger in Safari for Mac OS X
the user can set, customize her/his preference in pixels for the medium value (default, initial value is 16px). The webpage does not mention, indicate the Safari version. Anyway... I am sure Myles Maxfield can tell for the latest version of Safari.

[AmeliaBR]

Thanks for the help @TalbotG. Unfortunately, both of those How-To's seem to be out of date.

I'm using Safari via an online testing tool, so I may not be seeing all the options, but there is no "Appearance" tab in the settings dialog, going back as far as Safari 6.

Edge has font-size controls in its "Reading Mode" view, but those don't affect regular page rendering (and in reading mode, they are implemented by changing the font size on the root <html> element, and using rem units in the text, not through the keywords).

Thanks for the information about other browsers/rendering engines.

[TalbotG]

I'm using Safari via an online testing tool

I am curious. What is such online testing tool you're using?

there is no "Appearance" tab in the settings dialog, going back as far as Safari 6.

You are most likely right. I can not find anything related to Safari 11 in recent webpages or videos.

---

Mac OS X can set at os level the default font size according to
How to Increase All System Font Size in Mac OS X May 23, 2016

---

iPhone and iPad allow users to customize the default, medium font size via a slider with 7 preset values.
How to Increase/Decrease Text Size in iOS 11/11.1/11.2/11.3 on iPhone/iPad March 30th 2018

[AmeliaBR]

I am curious. What is such online testing tool you're using?

I'm using Cross Browser Testing; it has a free integration with CodePen that is great for testing quick snippets across many browsers & devices. It also has many other more complex testing features, but they require a paid account.

[mrmazda]

There is no material difference in how a user adjusts his font preference in Safari vs. Gecko browsers. Both with the most common displays by default assume 96 DPI and 16px until such time as the user chooses to make a change. With HiDPI displays, it works the same way, but the physical meaning of a px is changed to compensate for the higher physical density. CSS medium in all is thus 16px until a user chooses to personalize.

Konqueror, depending on version, provides a choice between WebKit and KHTML rendering engines. Its initial default size is 12pt (pt that depends on display density, as in CSS2; not pt that equals px, as in CSS3). e.g., 16px on a 96 DPI display, 22px on a 132 DPI display, and 28px on a 168 DPI display.

Edge has subsumed the concept of a default text size within the scaling knob it calls "Zoom", a simplified way to make everything bigger or smaller than the shipped default. This is a bit like what Gecko users asked for WRT text size as long as 18 years ago and never have gotten:
https://bugzilla.mozilla.org/show_bug.cgi?id=31961
https://bugzilla.mozilla.org/show_bug.cgi?id=96096
https://bugzilla.mozilla.org/show_bug.cgi?id=332275

Whatever numerical value may be assigned to the default or medium size, or its CSS px equivalent, really is of no importance to a user, and should be of no direct importance to web authors. The default size is presumptively the optimal size for every web user. Medium is an ideal pseudonym for the default, and should be, like its CSS equivalent, 1rem, the unit upon which all CSS sizes should ultimately be based.

Medium should never have been removed from the specification in the first place. It's one of the few hints that CSS is supposed to be a language of suggestion that leaves ultimate control in possession of the reader, the only possible person who can determine the optimal text size for the display in front of his eyes.

[TalbotG]

MS Edge and Safari don't have any option,
in the browser or OS level, to set a user preferred font-size.
So with two rendering engines implementing this behavior, and the other two not contradicting it

There is an option in the browser in MS-Edge to set an user preferred font-size: with only 4 predefined values. Firefox and Chrome grant more latitude, leeway and fine flexibility than MS-Edge.

[svgeesus]

It still comes down to this, as @AmeliaBR said:

For me, the first question is: do browser's implement it this way? That is, do they adjust the actual value of font-size: medium text to match the user's preferred setting, or do they match it to an absolute value?

Whether browsers offer an option to adjust preferred font size (they do) and whether this is an accessibility benefit (it is) and the precise UI employed and how this scale or zoom is presented to the user, is not the issue here. The issue is, having changed the size, does the browser update what medium (and all the other keywords) mean?

Testing with Amelia's pen in Firefox (60.0b15) Chrome (Canary 68.0.3406.0) and Edge (EdgeHTML 17.17134) all three sizes (100%, medium, 16px) were the same, and all scaled together when zooming. Text can be made as large as you like, and everything scales together. So the low vision accessibility requirement is met, and also is more robust in the real world regardless of how the font size was set; the design scales fluidly.

[svgeesus]

Also in Amelia's pen, in Chrome, if I go into settings and change the font size from the default Medium (recommended) to Very Large then 100% and medium both get bigger but 16px stays the same. Same for Firefox, if I change the default size from 16px to, say, 32px.

Which means that:

• some web site show bigger text, others wont
• only websites that are carefully constructed (for example by using all em units) will scale; the ones that use a mix of pt, px, em etc will not

I can see why zooming is a more preferred, and more robust, way to meet the accessibility requirement.

[TalbotG]

The issue is, having changed the size, does the browser update what medium (and all the other keywords) mean?

When users change the size, they are in fact defining, setting the medium size in the user agent style sheet. So, any web author who styles in his/her [author] style sheet, say,

body {font-size: 13px;}

will most likely (and very often) override the user preferred font size for unstyled body text (assuming here that the user prefers a font size different from 13px) when users visit such author's website because that is how cascade order (by origin) works: author (normal or !important) declarations always have precedence over user agent declarations.

some web site show bigger text, others wont
only websites that are carefully constructed (for example by using all em units) will scale; the ones that use a mix of pt, px, em etc will not

Unfortunately, a huge majority of websites will not respect, will not rely on the user's preferred font size. And, as a consequence of this, web accessibility advocacy groups or individuals will write post, blogs, articles, etc... explaining what is the medium font size and relying on that 9-words sentence ... that has been removed from CSS3 and CSS4.

---

One comment about the precise UI employed by browsers. Overall, it is bad and difficult to understand/to figure out (from an ordinary user perspective): AmeliaBR's own comments in this issue with regards to Chrome and MS-Edge supports me on this. But it is also a difficult goal too. That's why many browsers developped (starting around 2012-2014) Reading View and Reading Mode which represent an UI where the user can define an user style sheet with !important declarations.

[AmeliaBR]

Regarding accessibility:

Best practice for CSS authors is, and has always been, to define font sizes relative to the user's preferred font size. There are now three ways to do this, which all work equally well in the browsers that allow users to set a preferred font size:

• use only percentage sizes or em units; this, however, makes font sizes dependent on the nesting structure of your DOM: a <small> inside an <aside> may get a different font size than a <small> in the main text, if the <aside> has a different font size from the main text.

• use the keyword font sizes; the downside is that the relative difference between keywords can vary between browsers, so this is best only for resetting paragraph text to medium

• use rem units, and never change the font-size on the root element; this is what I currently recommend, now that rem has fairly good browser support.

Sadly, far too many web pages do not follow this best practice. So browsers offer a second option: zooming the definition of a pixel. The major downside to this is that it zooms everything on the page, creating blurry images and sometimes strange layouts. It's wonderful that browsers provide this option, but it doesn't replace the benefits of having customizable default font sizes.

Regarding this issue in particular:

If the only user agents that support customizable font sizes (i.e., changing the default font size as measured in px) also adjust the keywords to match, that should be in the spec. User agents aren't required to support a user-customizable default font size, but if they do, the user setting must also affect the keywords.

In other words, the following settings on the root element should always be equivalent, and the same as having no font-size declaration at all on the root element:

:root {
  font-size: 100%;
  font-size: 1rem;
  font-size: medium;
  font-size: initial;
}

(and that all the other keywords should adjust up or down relative to medium).

In this way, accessibility guides can continue to recommend that authors always use medium text body text, confident that it will adjust to user preferences, regardless of whether the user adjusts the default font size or the overall browser zoom level.

[TalbotG]

Best practice for CSS authors is, and has always been, to define font sizes relative to the user's preferred font size.

That is 1 recommended practice. Many accessibility-oriented, accessibility-advocacy websites also recommend to avoid size smaller than the user's preferred font size.

There are now three ways to do this

I think there are 4 ways.
em unit is one way.
Not setting a size for the text in the body is another recommended way by many authors (John Allsop, Dan Tobias, Chris Beal, Nick Theodorakis, Stephen Poley, Jim Wilkinson and I know there are others). That is what I do, by the way, in my own website.
rem unit: the only specificity of rem unit in comparison to em unit is that it avoids the compound effect of cascade: it is a stable and more predictable (easier to manage) value for CSS coders.

a <small> inside an <aside> may get a different font size than a <small> in the main text, if the <aside> has a different font size from the main text.

The only way to be sure of this is to examine the user agent style sheet for <aside> and <small>.
In Chrome 26.0.1410.63 and in Firefox 20, the rule in the user agent style sheet was:
small, sub, sup {font-size: smaller;} /* Appendix D gives small, sub, sup {font-size: .83em} */
and back then, font-size: smaller meant 2 distinct and different scaling factor for those 2 browsers.

In an ideal web-world, manufacturers of browsers would use the exact same user agent style sheet and web authors would not bother, would not wonder and would not struggle or hesitate about any of such issues and questions.

use the keyword font sizes; the downside is that the relative difference between keywords can vary between browsers, so this is best only for resetting paragraph text to medium

That is possible (I have not checked this) but it is unlikely (otherwise this is not optimal, not interoperable) as it would be a reason to complaint and to demand cross-browser compatibility. I know that smaller and larger keywords meant in 2012 something different for Chrome, Firefox and Opera (Presto engine).
smaller keyword meant

• a scaling factor of 1.5 for Firefox 10
• a scaling factor of 1.2 for Chrome 17
• a scaling factor of 1.25 for Opera 11.6
  font-size-118 : 'font-size: smaller'
  I do not know about today...

[AmeliaBR]

I think there are 4 ways. em unit is one way.

Ah, of course. I have edited my previous post to include that in with percentages, as it works the same, and has the same drawbacks (gets compounded by inheritance).

That is possible (I have not checked this)

I just checked. With the preferred font size of medium = 16px, Chrome, Firefox, and WebKit all use 10/13/16/18/24px for x-small, small, medium, large, x-large. Edge and IE use almost the same, but allow decimal sizes: 10.06/13.33/16/18.06/24px. So, that is fairly consistent currently, even if it is not explicitly spec'd anywhere. As you noted, there is discrepancy for the larger/smaller keywords, but Firefox, Chrome & WebKit seem to have converged on the same 1.2 factor; but this also means that only IE/Edge have it coded so that large is equal to one size larger than medium.

But anyway: all that just goes to confirm that the keywords are not absolute in pixel measurements, but relative to the browser defaults, with medium as the overall default font-size, which some browsers allow the user to customize.

[TalbotG]

Firefox 52.7.3 results of AmeliaBR's codepen test page for larger and smaller only:
larger than medium: 18px
smaller than medium: 13px
larger than x-large: 32px
smaller than x-large: 18px

Such result complies with CSS2.2 (xx-large is 32px in both Chromium 64 and Firefox 52):

A keyword is interpreted relative to the table of font sizes and the font size of the parent element. Possible values are: [ larger | smaller ]. For example, if the parent element has a font size of 'medium', a value of 'larger' will make the font size of the current element be 'large'.

coming from CSS 2.2, § 15.7 font size, <relative-size>

Chromium 64.0.3282.119 results of AmeliaBR's codepen test page for larger and smaller only:
larger than medium: 19.2px
smaller than medium: 13.3333px
larger than x-large: 28.8px
smaller than x-large: 20px

Such results are close but not perfectly, not accurately complying with CSS2.2. Such results clearly indicate a fixed, rigid scaling factor of 1.2 for Chrome.

[svgeesus]

Removing Fonts-3 label, if we do decide to change the spec here it would be Fonts-4

[TalbotG]

Why?
CSS Fonts Module Level 3
is a CR. Why change CSS4 spec but not change the CSS3 spec accordingly?

[svgeesus]

We would never have shipped CSS1 if we had continued tweaking it until it attained some ever-receding perfection.

I'm also far from convinced that changing the spec in a direction that is now what is implemented, just because of a statement that used to be in CSS 1 and 2, is the right thing to do. And since the discussion here does not seem close to resolution, holding back Fonts 3 because of it is a bad idea.

Fonts 4 is the current active spec (for example, browsers now implement font-weight as a number 1 to 999, like Fonts 4 says, not as an enumeration 100, 200 etc like Fonts 3 says.

Fonts 3 is the first full definition of webfonts. Webfonts are now used by around 75% of the top 10,000 websites. It is way past time for Fonts 3 to become a W3C Recommendation.

[TalbotG]

I'm also far from convinced that changing the spec in a direction that is now what is implemented, just because of a statement that used to be in CSS 1 and 2, is the right thing to do.

The reality is: mainstream browsers (Firefox, Chrome, Edge, Safari, Opera) treat and consider 'medium' value to be the user's preferred font size. This is not a wish. This is not enhancement request. This is reality.

since the discussion here does not seem close to resolution

I do not understand why you are saying that.

CSS3 Fonts says:

The ‘medium’ value is used as the reference middle value.

and what I am asking for (which is already in CSS2.x) is:

The 'medium' value is the user's preferred font size and is used as the reference middle value.

The difference is exactly these 7 words:

is the user's preferred font size and

[TalbotG]

I did not bring the discussion on the scaling factor of smaller and larger keywords. This should probably be testcase-ed and reported appropriately as a bug report to related browser manufacturers.

Which GUI browsers develop to allow users to set their preferred font size for normal text is - albeit an interesting discussion to have - not the purpose of this issue.

The only thing really involved in this issue are those above-mentioned 7 words missing.

[css-meeting-bot]

The Working Group just discussed font-size: 'medium' value is the user's preferred font size, and agreed to the following:

• RESOLVED: no change to spec, leave piece of text out

The full IRC log of that discussion

<dael> Topic: font-size: 'medium' value is the user's preferred font size
<dael> github: https://github.com//issues/2430
<dael> chris: It seems...I thought this effected impl and rereading i t looks like this should be t he users default, apperently it already does impact medium. it's restoring language that was in the spec and was removed. Thought it was a change, but I no longer object. We can put the language back. I'd like to hear i f other vendors see a problem. Otherwise trivial change
<dael> myles: One thought. Proposal has changed through issue. In Apr 25 post from Amelia it says [reads]. I think that's more specific than original text. Helps me understand what text trying to say. If we make a change, should be one Amelia proposed
<dael> Rossen: You're okay with changes?
<dael> myles: Yeah
<dael> dbaron: One thing we've found in past is if you change the meaning of medium and default font size meaning many web pages break. Turns out to not be a good thing rather then zooming. Maybe that's changing as web changes
<dael> myles: One detail, we don't support changing meaning of medium, but do support bumping every font size by a %. No way to effect keywords without effecting font-sizes and that works well
<dael> chris: I thinkt hat was the basis for my original reluctance. We seemed to hope that would work in CSS 1, but now you can zoom entire page and that seems more robust and what people do. didn't want to restore on basis of it was in css2.
<dael> myles: Q for dbaron. If you change definition of medium to other then 16 pages break, but someone in the issue said chrome and ff allow changing definition of medium
<dael> dbaron: We do have a setting and over time it has gotten more hidden, but haven't removed. It's not a great idea to set.
<astearns> I have changed that setting and have had pages break
<dael> Rossen: What does that leave for this issue?
<chris> so we shouldn't really encourage changing it, then
<dael> myles: This is a natural pull between browsers custom a11y that they do without spec changes vs something normative the spec can say about how to improve font sizes. dbaron comment on how browsers evolved their solution and maybe normative spec text isn't nec makes sense. Could go either way
<dael> chris: Could go either as well. Don't want to encourage people to do a bad practice
<dael> Rossen: Leaning resolve no change?
<tantek> I don't think we have enough data to justify a specific change on this
<chris> fine with no change here if WG so resolves
<dael> Rossen: Going to take silence as agree
<tantek> +1
<dael> Rossen: Objections to no change to spec, leave piece of text out
<chris> +1
<dael> RESOLVED: no change to spec, leave piece of text out