Intent to Ship: Auto range support for font descriptors inside @font-face rule

80 views
Skip to first unread message

Munira Tursunova

unread,
Oct 18, 2022, 11:27:04 AM10/18/22
to blin...@chromium.org, Dominik Röttsches

Contact emails

moo...@chromium.org, dr...@chromium.org


Explainer

https://bugs.chromium.org/p/chromium/issues/detail?id=973194

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


Specification

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


Summary

Auto range support for variable fonts in 'font-weight', 'font-style' and 'font-stretch' descriptors inside '@font-face' rule.


Motivation

Variable fonts provide users the opportunity to choose how heavy or slanted or wide the typeface should be, rather than having those decided by the type designer.


For variable fonts, in Chrome, it is required to add the supported range for 'font-weight', 'font-style' and 'font-stretch' descriptors inside @font-face rule, otherwise variable fonts would either be synthesizing bold faces or the text will appear as normal. 


In CSS WG issue 2485 it was resolved to add a default keyword 'auto'.


Blink component

Blink>Fonts


Search tags

auto range, variable fonts, font-weight, font-style, font-stretch


TAG review

Already shipped in other browsers, see below, no TAG review required.

TAG review status

Not applicable, existing standard, shipped in other UAs


Risks



Interoperability and Compatibility

Low, feature already shipped in Firefox and Safari.


Gecko: Shipped/Shipping Variable fonts work without specifying the supported range, however the browser does not yet support auto value parsing. Tests for 'font-stretch' and 'font-weight' descriptors are passing. Although the 'font-style' descriptor has a bug when it is synthetically obliquing out of the supported range.


WebKit: Shipped/Shipping Variable fonts work without specifying the supported range, however the browser does not yet support auto value parsing. Tests for 'font-stretch' descriptors are passing. Although the 'font-weight' descriptor works without specifying the range, there are some pixel differences in the test results. 'font-style' descriptor looks like it is synthesizing oblique faces.


Web developers: Positive (https://bugs.chromium.org/p/chromium/issues/detail?id=973194)

Content authors have been running into this counterintuitive problem of not seeing their variable fonts working without explicitly specifying the range. A UX engineer at Google, for example, faced this issue when she wasn’t able to use font-weight property without specifying the supported range for the variable font. That’s what she said: “It would be useful if the variable fonts behavior was always consistent with normal fonts, where you don't need to declare font-weight within @font-face”


Activation

None expected; Feature already implemented in other browsers.



Debuggability

Same as existing descriptors, @font-face rules inspectable in DevTools.



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

Yes. ‘auto’ keyword parsing tests for each descriptor; Added WPT tests for variable and static fonts for ‘font-weight’, ‘font-style’ and ‘font-stretch’ descriptors. 


Flag name

CSSFontFaceAutoVariableRange


Requires code in //chrome?

No


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=973194


Estimated milestones

109


Anticipated spec changes

None expected



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5173271981457408


Yoav Weiss

unread,
Oct 18, 2022, 11:52:19 PM10/18/22
to Munira Tursunova, blin...@chromium.org, Dominik Röttsches
On Tue, Oct 18, 2022 at 5:27 PM 'Munira Tursunova' via blink-dev <blin...@chromium.org> wrote:

That's restricted to Google folks, so not great as a public explainer. It's also not very descriptive.
Can you write a few words inline about what how those ranges are used, what developers typically do with them, and what are the implications on the font download (if any)?
  

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


Specification

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


Summary

Auto range support for variable fonts in 'font-weight', 'font-style' and 'font-stretch' descriptors inside '@font-face' rule.


Motivation

Variable fonts provide users the opportunity to choose how heavy or slanted or wide the typeface should be, rather than having those decided by the type designer.


For variable fonts, in Chrome, it is required to add the supported range for 'font-weight', 'font-style' and 'font-stretch' descriptors inside @font-face rule, otherwise variable fonts would either be synthesizing bold faces or the text will appear as normal. 


In CSS WG issue 2485 it was resolved to add a default keyword 'auto'.


Blink component

Blink>Fonts


Search tags

auto range, variable fonts, font-weight, font-style, font-stretch


TAG review

Already shipped in other browsers, see below, no TAG review required.

TAG review status

Not applicable, existing standard, shipped in other UAs


Risks



Interoperability and Compatibility

Low, feature already shipped in Firefox and Safari.


Gecko: Shipped/Shipping Variable fonts work without specifying the supported range, however the browser does not yet support auto value parsing.


Is what they are shipping interoperable with what you want to ship here? 
 

Tests for 'font-stretch' and 'font-weight' descriptors are passing. Although the 'font-style' descriptor has a bug when it is synthetically obliquing out of the supported range.


WebKit: Shipped/Shipping Variable fonts work without specifying the supported range, however the browser does not yet support auto value parsing. Tests for 'font-stretch' descriptors are passing. Although the 'font-weight' descriptor works without specifying the range, there are some pixel differences in the test results. 'font-style' descriptor looks like it is synthesizing oblique faces.


Web developers: Positive (https://bugs.chromium.org/p/chromium/issues/detail?id=973194)

Content authors have been running into this counterintuitive problem of not seeing their variable fonts working without explicitly specifying the range. A UX engineer at Google, for example, faced this issue when she wasn’t able to use font-weight property without specifying the supported range for the variable font. That’s what she said: “It would be useful if the variable fonts behavior was always consistent with normal fonts, where you don't need to declare font-weight within @font-face”


Activation

None expected; Feature already implemented in other browsers.



Debuggability

Same as existing descriptors, @font-face rules inspectable in DevTools.



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

Yes. ‘auto’ keyword parsing tests for each descriptor; Added WPT tests for variable and static fonts for ‘font-weight’, ‘font-style’ and ‘font-stretch’ descriptors. 


Flag name

CSSFontFaceAutoVariableRange


Requires code in //chrome?

No


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=973194


Estimated milestones

109


Anticipated spec changes

None expected



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5173271981457408


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C2%3DsXW53%2B08RULQvLXfWLqmxfmQ5ix%3D%3DV8qXhtbGhgAg%40mail.gmail.com.

Dominik Röttsches

unread,
Oct 19, 2022, 4:14:40 AM10/19/22
to Yoav Weiss, Munira Tursunova, blin...@chromium.org
Hi Yoav,

On Wed, Oct 19, 2022 at 6:52 AM Yoav Weiss <yoav...@chromium.org> wrote:


On Tue, Oct 18, 2022 at 5:27 PM 'Munira Tursunova' via blink-dev <blin...@chromium.org> wrote:

That's restricted to Google folks, so not great as a public explainer. It's also not very descriptive.

FWIW, I made the bug public. Additional explanations / explainer will follow. 

Dominik

Munira Tursunova

unread,
Oct 19, 2022, 8:29:19 AM10/19/22
to Dominik Röttsches, Yoav Weiss, blin...@chromium.org

Hi Yoav,


Thank you for your comments. Here are some of the answers to your questions from the chat:


> What would Firefox/Safari do when users start using the "auto" value? Are they planning to add support for it?


When they cannot parse the “auto” value they will use the default value, which for the case with variable fonts is the supported range and for non variable fonts in normal.


>What are the default picked characteristics? Are they specified? Are they the same for all implementations? 


Yes, the default font characteristic is same for every browser, in other words, if you are not specifying ‘font-weight’, ‘font-style’ or ‘font-stretch’ descriptors at all, the font will be regular and will look same in every browser, i.e. not bold, not obliqued and not widened.


On Wed, Oct 19, 2022 at 6:52 AM Yoav Weiss <yoav...@chromium.org> wrote:


On Tue, Oct 18, 2022 at 5:27 PM 'Munira Tursunova' via blink-dev <blin...@chromium.org> wrote:

That's restricted to Google folks, so not great as a public explainer. It's also not very descriptive. 
Can you write a few words inline about what how those ranges are used, what developers typically do with them, and what are the implications on the font download (if any)?

Currently if you want to use variable font and write something like this: 


@font-face {

       font-family: "Roboto";

       src: url('support/fonts/RobotoExtremo-VF.subset.ttf');

}

 

In Chrome it would be considered as: 


@font-face {

       font-family: "Roboto";

       src: url('support/fonts/RobotoExtremo-VF.subset.ttf');

       font-weight: normal;

       font-style: normal;

       font-stretch: normal;

}

The range of the available values would be clamped to normal, so, for example if later you want to use bolder text for the following @font-face, the bold faces would be synthesized and the whole functionality of variable fonts would be lost.


According to the current spec https://www.w3.org/TR/css-fonts-4/#font-prop-desc, the new keyword ‘auto’ works as follows:

  • For static fonts auto means normal, in other words “font-weight: auto” for those means “font-weight: normal”.

  • For variable fonts auto is  the supported range, “font-weight: auto” would be “font-weight: <lower_bound_of_the_supported_range> <upper_bound_of_the_supported_range>” depending on what ranges the font supports.

  • ‘Auto’ is the initial  value for the for ‘font-weight’, ‘font-stretch’ and ‘font-style’ descriptors inside @font-face rule, so, if, for example “font-weight” descriptor is not specified in @font-face rule at all then for static fonts it will considered as normal value and for variable fonts – the supported font range.


Interoperability and Compatibility

Low, feature already shipped in Firefox and Safari.


Gecko: Shipped/Shipping Variable fonts work without specifying the supported range, however the browser does not yet support auto value parsing.


Is what they are shipping interoperable with what you want to ship here? 

The main goal of the feature is that it is not required to specify the supported range in the descriptors and Safari and Firefox already implement and support that. The part that they are missing is ‘auto’ keyword support, however if, for example the ‘auto’ keyword is set for ‘font-weight’ descriptor, i.e. “font-weight: auto;”, they will fail to parse this line and the initial value will be applied for the descriptor, so for variable fonts it would be internally set to the supported range and for static fonts the ‘normal’ value. So if you look at the tests font-face-*-auto-variable.html in https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned they describe the above mentioned situation and some of them are already passing in Firefox and Safari, more information in the ‘Interoperability and Compatibility’ sections in the original email.

We consider the lack of parsing an explicit `auto` correctly a bug in Safari and FF and filed the corresponding bug reports for Safari and Firefox. From an interoperability point of view, we don’t think that is a critical issue as authors are not expected and not encouraged to use an explicit `auto` value.

Philip Jägenstedt

unread,
Oct 19, 2022, 8:39:18 AM10/19/22
to Munira Tursunova, Dominik Röttsches, Yoav Weiss, blin...@chromium.org
Thanks Munira for the detailed explanation, and thanks for filing the Gecko and WebKit bugs!

I think that from a web developer's point of view, this won't be a feature that you actively use, but sensible defaults and the lack of a surprising behavior/bug. Thanks for sorting that out!

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Mike Taylor

unread,
Oct 24, 2022, 10:47:13 AM10/24/22
to Philip Jägenstedt, Munira Tursunova, Dominik Röttsches, Yoav Weiss, blin...@chromium.org

Yoav Weiss

unread,
Oct 25, 2022, 1:03:46 AM10/25/22
to Mike Taylor, Philip Jägenstedt, Munira Tursunova, Dominik Röttsches, blin...@chromium.org
LGTM3

I think there's some interop risk here if Apple and Mozilla won't add support for explicit "auto" values and developers would start using them, but I agree that there's no real incentive for developers to do so.
Reply all
Reply to author
Forward
0 new messages