Intent to Ship: Auto range support for font descriptors inside @font-face rule
Munira Tursunova
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
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
Yoav Weiss
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
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
--
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
On Tue, Oct 18, 2022 at 5:27 PM 'Munira Tursunova' via blink-dev <blin...@chromium.org> wrote:Contact emails
moo...@chromium.org, dr...@chromium.org
Explainer
https://bugs.chromium.org/p/chromium/issues/detail?id=973194
That's restricted to Google folks, so not great as a public explainer. It's also not very descriptive.
Munira Tursunova
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 Tue, Oct 18, 2022 at 5:27 PM 'Munira Tursunova' via blink-dev <blin...@chromium.org> wrote:Contact emails
moo...@chromium.org, dr...@chromium.org
Explainer
https://bugs.chromium.org/p/chromium/issues/detail?id=973194
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.
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
--
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_CZdxUcvWtqoSpf9HuMqRqCMOPgd9qwi86%3Do7Uv2EpGDw%40mail.gmail.com.
Mike Taylor
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcsuS9N-e3R8TCjWNuR-knQo4p504TSR8Fwm%2BnuoLNeCA%40mail.gmail.com.