Which milestone are you aiming for? On Friday, June 18, 2021 at 7:57:58 AM UTC-7 dr...@chromium.org wrote:
> Contact emailsdr...@chromium.org > > Specificationhttps://drafts.csswg.org/css-fonts/#font-face-src-parsing > > API specYes > > Summary > > 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. > > > Blink componentBlink>Fonts > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts> > > Search tagscss <https://chromestatus.com/features#tags:css>, @font-face > <https://chromestatus.com/features#tags:@font-face>, src > <https://chromestatus.com/features#tags:src>, descriptor > <https://chromestatus.com/features#tags:descriptor>, src descriptor > <https://chromestatus.com/features#tags:src%20descriptor> > > TAG review > > TAG review statusNot applicable > > Risks > > 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 > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ?No, WPT tests will be added while completing implementation work > <https://chromium-review.googlesource.com/c/chromium/src/+/2940647> of > this feature. > > > Tracking bughttps://crbug.com/1216460 > > Link 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6676096-1782-4c98-9a25-a945993a494fn%40chromium.org.
