Intent to Ship: tech() function support in @font-face src: descriptor

[Dominik Röttsches]

Contact emails

dr...@chromium.org

Explainer

None

Specification

https://www.w3.org/TR/css-fonts-4/#font-face-src-parsing

Summary

CSS Fonts Level 4 provides additional means of selecting or filtering font resources. The tech() function was introduced, which allows passing in a list of font technologies that this respective font blob requires to function. Based on that, the UA will select the first suitable resource.

I will hold shipping until one remaining clarification is reached on whether the keywords should be phrased in singular or plural form, compare item 3 in https://github.com/w3c/csswg-drafts/issues/7633.

Motivation

With COLRv1 font supports, it's now more important to give authors an opportunity to check feature support. Doing this in the tech() function in the src: descriptor of @font-face is one useful tool for incremental upgrade of the user experience. If the UA supports COLRv1 or other new font technologies, the richer font is loaded, otherwise fallback occurs.

Blink component

Blink>Fonts

TAG review

https://github.com/w3ctag/design-reviews/issues/666

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Gecko: Positive https://github.com/mozilla/standards-positions/issues/563

WebKit: No signal

Web developers: In discussions with partners before launching COLRv1, feature detection for COLRv1 was a requested functionality. The src: line tech() function is one way to achieve that.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

Limited debuggability but unchanged to before: @font-face declarations are viewable as source in DevTools, but otherwise no particular tooling support is provided. However this is unchanged from before, as this change only affects the syntax inside the @font-face src: line.

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, initial tests provided by Jonathan Kew from Mozilla, which I then updated, see https://github.com/w3c/csswg-drafts/issues/7633 and https://github.com/web-platform-tests/wpt/pull/35681

Flag name

CSSFontFaceSrcTechParsing (Blink RuntimeEnabledFeatures flag)

Requires code in //chrome?

No

Tracking bug

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

Estimated milestones

107

Anticipated spec changes

See above, holding shipping until clarification is reached on singular or plural naming of features- keywords.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5088679224147968

[Dominik Röttsches]

(re-sent from @chromium.org address)

[Yoav Weiss]

On Monday, August 29, 2022 at 3:09:39 PM UTC+2 Dominik Röttsches wrote:

(re-sent from @chromium.org address)

Contact emails

dr...@chromium.org

Explainer

None

I think that a short explainer outlining exactly what you're planning to ship here and how you're expecting developers to use it would be helpful. Can you add one? (potentially even inline, if it's rather short)

[Philip Jägenstedt]

On Wed, Aug 31, 2022 at 4:11 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Monday, August 29, 2022 at 3:09:39 PM UTC+2 Dominik Röttsches wrote:

(re-sent from @chromium.org address)

Contact emails

dr...@chromium.org

Explainer

None

I think that a short explainer outlining exactly what you're planning to ship here and how you're expecting developers to use it would be helpful. Can you add one? (potentially even inline, if it's rather short)

Perhaps a small edit to https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md to say what this is for and give an example?

Some text from https://drafts.csswg.org/css-fonts-4/#ex-color-if-supported could be lifted. Spelling out what the different keywords in tech(keyword) do in plain language would be helpful.

[Alex Russell]

We discussed this at today's API OWNERs meeting and, while I realise I should perhaps be directing most of these comments at the CSS WG more broadly, I'm concerned that the bundle of features that this function is designed to support are not clearly articulated, which argues for an explainer and perhaps a TAG review.

Specifically:

• What problems do the "variations", "palettes", and "incremental" values address? There should be clear enunciation of those issues in an explainer, a discussion of considered alternatives, and example code describing how this specfic design best meets those needs.
• Related, why is "tech()" overloaded for whatever those values do as well as explict named technologies and sub-features?
• Since we're going first, and the only group that seems to have looked at this is the CSS WG, shouldn't there be a TAG review?

The CSS WG continues to work outside of our incubation and explainer-based model for feature development, and as a general matter it's not OK.

I realise this feature is hostage to a bad work mode and it isn't the developer's of this syntax's fault, but we need to break the cycle.

Future CSS features that do not incubate, center developer feedback (perhaps through OT), and show signs of incubation may also invoke delays from me.

Regards,

Alex

[Dominik Röttsches]

Hi Yoav, Alex,

Yoav wrote:

I think that a short explainer outlining exactly what you're planning to ship here and how you're expecting developers to use it would be helpful. Can you add one? (potentially even inline, if it's rather short)

 

As Philip points out, the explainer can be found here which was also used for the previously filed TAG review. I just updated it for the new syntax. My bad for not adding it in the initial post.

Yoav, re your question what is it that I want to ship:

Parsing and filtering resources in the @font-face src: descriptor line in Blink does currently not understand the tech() function. I want to bring Blink to the spec level, make it understand the tech() function and filter fonts accordingly. That means not adding src: line components to the list of font blobs to be downloaded which are not supported in Blink. E.g. (features-graphite, color-SVG). CL for reference with feature behind flag here. 

[...] and how you're expecting developers to use it would be helpful [...]

 

The explainer lists 3 main use cases. 

For more context: 

This intent to ship is a follow-up from an earlier attempt to ship a previous form of this feature and syntax. In the I2S then a TAG review was requested, TAG review here. 

The TAG suggested changes, the syntax was updated, and @supports(font-tech()) feature was added to CSS Conditionals 5 and keywords between these two features were harmonised.

Alex wrote:

We discussed this at today's API OWNERs meeting and, while I realise I should perhaps be directing most of these comments at the CSS WG more broadly, I'm concerned that the bundle of features that this function is designed to support are not clearly articulated, which argues for an explainer and perhaps a TAG review.

Specifically:

• What problems do the "variations", "palettes", and "incremental" values address? There should be clear enunciation of those issues in an explainer, a discussion of considered alternatives, and example code describing how this specfic design best meets those needs.

The specification lists what the particular terms mean and what browser font support they address:

https://drafts.csswg.org/css-fonts-4/#font-tech-definitions

• tech(variations) then means that a UA understands the OpenType Variations functionality of this font resource.
• tech(palettes) then means that a UA can understand the CPAL color palette information in this font and is able to apply palettes to it using font-palette CSS. 
• tech(incremental) is forward looking and means that the UA can load this resource if it understands incremental font transfer. I am personally open to not shipping this particular keyword until UAs start implementing incremental transfer

Example code is in the explainer: https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md#examples. 

• Related, why is "tech()" overloaded for whatever those values do as well as explict named technologies and sub-features?

Do I understand your question right: Are you asking why tech() combines keywords that sound broader, and some that sound more specific to a particular technology? I.e. variations vs. color-COLRv0? These keywords and technologies are chosen as levels of font support that a UA may have. OpenType Variations support is one are of technology support, then the specific color font formats are other levels of support. I imagine they may sound unrelated or wide vs. specific, but from the perspective of evolution of font support in browsers, from my point of view they make sense as a means to describe feature support of the text stack. Does that answer your question?

• Since we're going first, and the only group that seems to have looked at this is the CSS WG, shouldn't there be a TAG review?

A TAG review was requested and concluded, which resulted in the updated syntax and the addition of @supports( font-tech() )  to CSS Conditionals 5. 

We are not the only ones shipping this: Firefox implemented and aims at shipping this and @supports( font-tech() ) very soon in one of the next upcoming releases, FF bugzilla #1786493. The feedback I hear from Jonathan Kew, their font expert: This feature is a useful part of shipping COLRv1 font support for selecting the right resource.

 

The CSS WG continues to work outside of our incubation and explainer-based model for feature development, and as a general matter it's not OK.

I realise this feature is hostage to a bad work mode and it isn't the developer's of this syntax's fault, but we need to break the cycle.

Future CSS features that do not incubate, center developer feedback (perhaps through OT), and show signs of incubation may also invoke delays from me.

As the implementer of this feature in Blink, and as you're indicating in your reply in terms of the audience of your feedback, I am not able to extract actionable feedback from this part other than encouraging the CSS WG to adopt this model or using it if I am driving a feature myself. Other than that, am I missing something from this part?

What do you exactly mean by "break the cycle" here? I do hope we can proceed with this feature - as this is the second iteration after the TAG review and earlier TAG and blink-dev feedback. 

Dominik

[Theodore Olsauskas-Warren]

(Chrome OWP Privacy reviewer drive-by)

I'm trying to understand whether the various tech() capabilities are directly derivable from already exposed information, and this is just a convenience, or whether otherwise identical UAs might give out different values based on the platform or user configuration. 

The privacy section in the spec about " What data does this specification expose to an origin?" seems silent on this,

Theo.

[Dominik Röttsches]

Hi Theo,

On Friday, September 2, 2022 at 3:07:04 PM UTC+2 Theodore Olsauskas-Warren wrote:

(Chrome OWP Privacy reviewer drive-by)

I'm trying to understand whether the various tech() capabilities are directly derivable from already exposed information, and this is just a convenience, or whether otherwise identical UAs might give out different values based on the platform or user configuration. 

The privacy section in the spec about " What data does this specification expose to an origin?" seems silent on this,

I think I answered a very similar privacy review question in the previous iteration of this I2S, in this thread, does this help? In short, in Chrome it is almost equivalent to the user agent major version, as we do not have platform specific differences in this level of font stack functionality.  

Hope this helps,

Dominik

[Philip Jägenstedt]

On Wed, Aug 31, 2022 at 6:02 PM Alex Russell <sligh...@chromium.org> wrote:

We discussed this at today's API OWNERs meeting and, while I realise I should perhaps be directing most of these comments at the CSS WG more broadly, I'm concerned that the bundle of features that this function is designed to support are not clearly articulated, which argues for an explainer and perhaps a TAG review.

Specifically:

• What problems do the "variations", "palettes", and "incremental" values address? There should be clear enunciation of those issues in an explainer, a discussion of considered alternatives, and example code describing how this specfic design best meets those needs.
• Related, why is "tech()" overloaded for whatever those values do as well as explict named technologies and sub-features?
• Since we're going first, and the only group that seems to have looked at this is the CSS WG, shouldn't there be a TAG review?

Dominik has updated the explainer and as it turns out the original TAG review even covered this aspect under the older syntax. Given that, I don't think it's meaningful to ask the TAG about this again. Alex, would you agree in light of the new information?

 

The CSS WG continues to work outside of our incubation and explainer-based model for feature development, and as a general matter it's not OK.

I realise this feature is hostage to a bad work mode and it isn't the developer's of this syntax's fault, but we need to break the cycle.

Future CSS features that do not incubate, center developer feedback (perhaps through OT), and show signs of incubation may also invoke delays from me.

To avoid misattribution, this framing isn't something that the API owners jointly agreed to in the meeting.

As for my 2c, our launch process doesn't require people to incubate outside of a WG, and indeed the "existing standard" path allows for additions/changes to existing specs in WGs, and this is very commonly how we ship new features. There's nothing preventing us or others from doing all the right things while doing the spec work in the CSSWG.

Best regards,

Philip

[Alex Russell]

Hey Dominik,

Thanks for getting back to me, the detail on the syntax, and for the link to the explainer. Thanks also for correcting me regarding the TAG review. I feel much better about the proposal as a result of all of this detail.

On the CSS WG aspects, if features are developed w/ epxlainers like this, as long as we're going first, it might make sense to use OT to road-test them with developers, but I won't stand on it here as the explainer is clear and, presumably, developers will weigh in with their support.

LGTM

Best,

Alex

[Chris Harrelson]

LGTM2

--
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/d49673b0-57c6-4cc3-ae75-7169c4c380f5n%40chromium.org.

[Philip Jägenstedt]

LGTM3

[Yoav Weiss]

Unrequired LGTM4! Thanks Dominik for the explainer :)