Support the extended `supports <font-technology>` syntax of the @font-face src: descriptor. The intention of this syntax is to enable UA's to choose supported entries from the src: line of the @font-face. Unsupported entries with "support..." lines which are not supported are to be dropped from the src: line.
Motivation
Supporting this syntax enables an inexpensive CSS or JS based check for support of CORLv1 or other font technologies.
CSS based selection of the right font and technology is done by the UA traversing the src: line and choosing the first successfully parsed and supported entry and trying to load it. If the load fails, the next supported entry is chosen.
JS feature testing can be achieved by declaring a CSS @font-face in a stylesheet with a src: line that contains for example a line src: format(woff2) supports COLRv1; - then accessing this rule using CSSOM and retrieving the value of cssText for this rule. By analysing the values of cssText, specifically the serialized src: line, it can be determined whether entries were dropped from the src: line.
Support for this feature across browsers allows precise selection of the best, supported font technology from the @font-face definition.
The `supports <font-technology>` is a backwards-compatible extension of the @font-face src: descriptor syntax. Existing values for the src: line which contain only string values such as format("woff2") for format("woff2-variations") will still be understood and working as intended. The CSSOM serialisation of the parsed value will be canonicalised to match the spec grammar. E.g. if the page specifies src: url(...) format("woff2") supports variations; it will be serialized as src: url(...) format(woff2) supports variations; to upgrade the syntax to the newer form in the spec. I expect low compatibility problems from that, because a) the format() syntax is not often used, b) I do not expect the serialisation of the value to be accessed much at all.
The CSS based selection of the font src: of the right technology works without ergonomic issues and is the spec-suggested approach for solving this problem. The JS based feature detection as described above is a more efficient check for supported font technology than using a canvas-based approach as for example used in https://pixelambacht.nl/chromacheck/. At the same time, it's still not as straight-forward compared to CSS.supports() JS syntax. However, CSS.supports() works only for CSS properties, not for descriptors of @font-face. In that sense, this is a spec-compliant approach that can be deployed now, while the spec discussion continues on whether a more direct JS based feature test for descriptor syntax should be added.
To some extent through DevTools. (Not much support exists for @font-face in general)
Not supported src: entries will be removed from the src: line and will not show up in DevTools. As such, DevTools helps to identify which types of entries are supported and how parsing of the src: line succeeded.
--
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/CAN6muBvJEc2pa1_pRWBSEktxHSEz_SnwjSyETVdoqpS_MXT1Gg%40mail.gmail.com.
/me takes off API owner hat and puts on my webperf person hat insteadI think it would make more sense to define those different font technologies as new MIME types or extensions to existing ones.That would enable performing that content negotiation on the client (by changing "format()"), on the server (using Accept headers) as well as enable preload support (for the latest variant), using the `type` attribute.
Even if extending the MIME types is not the right way to go, we need to think about those cases and make sure they are supported.Have y'all talked to folks that serve fonts using content negotiation?
Hi Yoav,Thanks for the feedback.On Mon, Jun 21, 2021 at 3:19 PM Yoav Weiss <yoav...@chromium.org> wrote:/me takes off API owner hat and puts on my webperf person hat insteadI think it would make more sense to define those different font technologies as new MIME types or extensions to existing ones.That would enable performing that content negotiation on the client (by changing "format()"), on the server (using Accept headers) as well as enable preload support (for the latest variant), using the `type` attribute.What do you mean by preload support, "latest variant" and "type attribute" here?
Even if extending the MIME types is not the right way to go, we need to think about those cases and make sure they are supported.Have y'all talked to folks that serve fonts using content negotiation?There's been the start of a discussion, yes, we had a thread with Mike Taylor and input from Evan Adams of Google Fonts on this. I've been wondering whether something like UA client hints for font formats would be the right method and useful addition for content negotiation (disclaimer: I am not very familiar with client hints yet and may lack sufficient understanding.)
I don't think extending MIME is the right way as what we're looking at in terms of formats is at a different level: the overall font format and high level file structure does not change between formats. Font formats in this respect here differ at the font table level within an overall similar file structure.
--TAG review status
Not applicableRisks
Interoperability and Compatibility
The `supports <font-technology>` is a backwards-compatible extension of the @font-face src: descriptor syntax. Existing values for the src: line which contain only string values such as format("woff2") for format("woff2-variations") will still be understood and working as intended. The CSSOM serialisation of the parsed value will be canonicalised to match the spec grammar. E.g. if the page specifies src: url(...) format("woff2") supports variations; it will be serialized as src: url(...) format(woff2) supports variations; to upgrade the syntax to the newer form in the spec. I expect low compatibility problems from that, because a) the format() syntax is not often used, b) I do not expect the serialisation of the value to be accessed much at all.
Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=650372)
WebKit: No signal (https://github.com/w3c/csswg-drafts/issues/633) Case made for "supports" syntax originally made my Myles Maxfield from Apple. Nevertheless, "supports" syntax extension not implemented in Safari yet.
Web developers: Positive
When working on COLRv1, we've received requests from prominent web partners for an efficient way of feature testing for COLRv1 availability. Implementing the supports syntax allows JS and CSS based feature detection for COLRv1.Ergonomics
The CSS based selection of the font src: of the right technology works without ergonomic issues and is the spec-suggested approach for solving this problem. The JS based feature detection as described above is a more efficient check for supported font technology than using a canvas-based approach as for example used in https://pixelambacht.nl/chromacheck/. At the same time, it's still not as straight-forward compared to CSS.supports() JS syntax. However, CSS.supports() works only for CSS properties, not for descriptors of @font-face. In that sense, this is a spec-compliant approach that can be deployed now, while the spec discussion continues on whether a more direct JS based feature test for descriptor syntax should be added.
Debuggability
To some extent through DevTools. (Not much support exists for @font-face in general)
Not supported src: entries will be removed from the src: line and will not show up in DevTools. As such, DevTools helps to identify which types of entries are supported and how parsing of the src: line succeeded.
Is this feature fully tested by web-platform-tests?
No, WPT tests will be added while completing implementation work of this feature.
Tracking bug
https://crbug.com/1216460Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5741063488667648
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+unsubscribe@chromium.org.
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/CAN6muBvJEc2pa1_pRWBSEktxHSEz_SnwjSyETVdoqpS_MXT1Gg%40mail.gmail.com.
--
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/e5a7290d-4897-42fe-a069-db7581dc89f9n%40chromium.org.
Friendly-pinging my friendly-ping on Yoav's question. :) Is this intent still active?
I was wondering whether this mechanism could reveal anything more granular than the major version of the user agent. Is it possible for font technology support to evolve faster than major UA versions (e.g. via OS stack updates, or in minor UA versions)? If not, would it be possible to add some text to the Security & Privacy Considerations section to indicate that browsers shouldn't use a minor version of the OS they're running on to decide whether a font feature is supported? This is to ensure that this feature cannot be used as a fingerprinting surface.
Web developers: Positive
When working on COLRv1, we've received requests from prominent web partners for an efficient way of feature testing for COLRv1 availability. Implementing the supports syntax allows JS and CSS based feature detection for COLRv1.Ergonomics
The CSS based selection of the font src: of the right technology works without ergonomic issues and is the spec-suggested approach for solving this problem. The JS based feature detection as described above is a more efficient check for supported font technology than using a canvas-based approach as for example used in https://pixelambacht.nl/chromacheck/. At the same time, it's still not as straight-forward compared to CSS.supports() JS syntax. However, CSS.supports() works only for CSS properties, not for descriptors of @font-face. In that sense, this is a spec-compliant approach that can be deployed now, while the spec discussion continues on whether a more direct JS based feature test for descriptor syntax should be added.
Debuggability
To some extent through DevTools. (Not much support exists for @font-face in general)
Not supported src: entries will be removed from the src: line and will not show up in DevTools. As such, DevTools helps to identify which types of entries are supported and how parsing of the src: line succeeded.
Is this feature fully tested by web-platform-tests?
No, WPT tests will be added while completing implementation work of this feature.
Dominik and I had a few discussions over the last few days which clarified the direction we want to take with font technologies and related content negotiation.I was initially concerned by the fact that these technologies are not well represented in the relevant mime type that can then be used for selection in preload and as part of the Accept header.But given the fact that preload's `type` based selection is breaking at the seams when it comes to image types as well as in the face of many different font features, with different levels of support across browsers, it seems like it may be time to design a separate selection mechanism there that wouldn't rely so heavily on mime types.Regarding `Accept`, after further thinking, I was not excited about adding the font capabilities to that header because: a) it may expose more passive entropy b) the content-negotiation for fonts is often needed when serving the stylesheet, and sending Accept values for fonts as part of the stylesheet request felt weird. Talking to the Privacy Sandbox folks, they seem to generally agree with (a) and that we may need an alternative mechanism to enable font capabilities based content negotiation.As such, I think it's fine that this feature is considering the various font capabilities as an orthogonal dimension to font formats and enabling client-side content-negotiation based on that. That seems like an important use case.
I think it'd make sense to ask for explicit signals from both Mozilla and Apple: bit.ly/blink-signals
Any links to artifacts of positive developer opinion?
I'm assuming it will be tested before shipping. Is that a correct assumption?
"We like the general use cases and proposed direction of this feature. However we're concerned about the replication of an existing feature, so before shipping we hope that you will work with the CSS Working Group to exhaust any existing CSS feature detection mechanisms such as @supports (see w3c/csswg-drafts#6520 as proposed example) before going after a new microsyntax solution."