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 On Wed, Oct 19, 2022 at 2:29 PM 'Munira Tursunova' via blink-dev < [email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> On Tue, Oct 18, 2022 at 5:27 PM 'Munira Tursunova' via blink-dev < >> [email protected]> wrote: >> >>> Contact emails >>> >>> [email protected], [email protected] >>> >>> 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. >> > > 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 > <https://bugs.webkit.org/show_bug.cgi?id=246742> and Firefox > <https://bugzilla.mozilla.org/show_bug.cgi?id=1796116>. 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. > > -- > 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_CZdxUcvWtqoSpf9HuMqRqCMOPgd9qwi86%3Do7Uv2EpGDw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. 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.
