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 <yoavwe...@chromium.org> wrote: > > > On Tue, Oct 18, 2022 at 5:27 PM 'Munira Tursunova' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emails >> >> moon...@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. > 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 blink-dev+unsubscr...@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.
