Hi, another update:
- The TAG review is now completed <https://github.com/w3ctag/design-reviews/issues/666#issuecomment-901220221> with positive feedback on the feature direction and recommendation to investigate whether a CSS Fonts specific micro-syntax can be avoided for example using a nested @supports syntax inside @font-face. TAG's wording: "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 <https://github.com/w3c/csswg-drafts/issues/6520> as proposed example) before going after a new microsyntax solution." - A positive signal on the feature from Apple: webkit-dev thread <https://lists.webkit.org/pipermail/webkit-dev/2021-August/031937.html> I'll investigate whether the proposal to use @supports inside @font-face is feasible and whether it adds too much complexity, then respond on the respective CSS WG issue 6520 <https://github.com/w3c/csswg-drafts/issues/6520> and see if we can conclude the discussion in the CSS WG and either agree on a new TAG friendly syntax or conclude that the existing micro-syntax is needed. Once that's done, I'll come back to this Intent To Ship. Dominik On Mon, Aug 9, 2021 at 5:55 PM Dominik Röttsches <[email protected]> wrote: > Hi Yoav, > > > On Fri, Jul 30, 2021 at 8:00 PM Yoav Weiss <[email protected]> wrote: > >> 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 <https://github.com/w3c/preload/issues/118> 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 >> <https://github.com/w3c/preload/issues/156> 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. >> > > Thanks for the discussion and this feedback. > > As you also suggested to still do a TAG review, as we'd be the first to > ship this feature, I filed a TAG review for the extended @font-face src: > supports() syntax <https://github.com/w3ctag/design-reviews/issues/666>. > > I think it'd make sense to ask for explicit signals from both Mozilla and >> Apple: bit.ly/blink-signals > > > Filed as > https://lists.webkit.org/pipermail/webkit-dev/2021-August/031935.html for > WebKit and > https://github.com/mozilla/standards-positions/issues/563 for Mozilla. > > Myles from Apple has been quite active in developing this syntax, compare CSS > WG issue 633 <https://github.com/w3c/csswg-drafts/issues/633>, which > makes me hopeful that Apple has a positive stance towards this feature even > though it's not shipping in Safari yet. > > Any links to artifacts of positive developer opinion? >> > > No public links, I have meeting minutes from speaking with partners, if > that helps. > > I'm assuming it will be tested before shipping. Is that a correct >> assumption? > > > Yes, of course. I'll develop WPT tests. > > Dominik > > > > On Tue, Jul 27, 2021 at 2:12 PM Dominik Röttsches <[email protected]> >> wrote: >> >>> As a quick update, Yoav and I had a good discussion which - at least I >>> can speak for myself - really helped improve the mutual understanding. >>> There's a few things we want to ask Google Fonts and other third-party font >>> providers in terms of how clues in an Accepts: header might be useful for >>> them for delivering the right CSS before we come back to resuming this >>> intent to ship. >>> >>> Dominik >>> >>> >>> On Tue, Jul 20, 2021 at 1:17 PM Dominik Röttsches <[email protected]> >>> wrote: >>> >>>> Hi Mike, Kaustubha, >>>> >>>> Friendly-pinging my friendly-ping on Yoav's question. :) Is this intent >>>>> still active? >>>>> >>>> >>>> This intent is still active, sorry for the delay in responding. Yoav >>>> and I were both out-of-office in overlapping periods of time. For myself, I >>>> was out the past two weeks and did not file the TAG review request before >>>> that. My intention was to have a 1:1 conversation with Yoav before I do >>>> that to align first. >>>> >>>> On Tue, Jul 13, 2021 at 8:04 PM Kaustubha Govind <[email protected]> >>>> wrote: >>>> >>>> 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. >>>>> >>>> >>>> I think the answer to your question depends on whether we look at a >>>> particular implementation or look at the spec conceptually: >>>> >>>> Speaking for Chrome, changes in which font technologies are supported >>>> would usually coincide with a major version of the user agent, indeed, or >>>> switching a flag on when using a rollout via Chrome variations/flags. In >>>> Blink, we use a hybrid font stack that is composed of the system font >>>> stack's rasterizing capabilities (DirectWrite, CoreText) combined with Skia >>>> +FreeType's rasterization capabilities to fill in gaps in the system >>>> rasterizer. Using this stack, we can provide support for all the font >>>> formats we support (OpenType variations, color font formats: COLRv0, SBIX, >>>> CBDT) on all OSes where we have our own engine (iOS excluded). This means >>>> we would not reveal any font technology support differences using this >>>> feature as we can cover the gaps with the Skia+FreeType backend. >>>> >>>> However, at the specification level, conceptually, this feature can >>>> reveal more than the user agent major version if in non-Chrome >>>> implementation platform font support differs and a UA provides different >>>> support on different platforms. Firefox, as an example, does not have a >>>> hybrid font stack capability so their font technology support differs on >>>> different platforms. So a correct implementation of this feature in a UA >>>> that supports some font technologies only on some platforms would reveal >>>> information about the underlying OS/platform as well - so the granularity >>>> is similar to UA major version + platform (Win, Mac, Linux, etc.). >>>> >>>> Dominik >>>> >>>> >>>> On Thu, Jul 15, 2021 at 10:45 AM Mike West <[email protected]> wrote: >>>> >>>>> Friendly-pinging my friendly-ping on Yoav's question. :) Is this >>>>> intent still active? >>>>> >>>>> -mike >>>>> >>>>> >>>>> On Thu, Jul 1, 2021 at 8:32 PM Mike West <[email protected]> wrote: >>>>> >>>>>> Friendly ping on Yoav's suggestion. Did y'all ask the TAG to weigh in? >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> On Thu, Jun 24, 2021 at 8:24 PM Yoav Weiss <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> /me puts his API owner hat back on >>>>>>> >>>>>>> On Tuesday, June 22, 2021 at 7:03:07 PM UTC+2 Yoav Weiss wrote: >>>>>>> >>>>>>>> On Mon, Jun 21, 2021 at 6:20 PM Dominik Röttsches < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Yoav, >>>>>>>>> >>>>>>>>> Thanks for the feedback. >>>>>>>>> >>>>>>>>> On Mon, Jun 21, 2021 at 3:19 PM Yoav Weiss <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> */me takes off API owner hat and puts on my webperf person hat >>>>>>>>>> instead* >>>>>>>>>> >>>>>>>>>> I 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? >>>>>>>>> >>>>>>>> >>>>>>>> Apologies for not being clearer... >>>>>>>> "preload support" - ability to preload such fonts with supported >>>>>>>> features in supporting browsers, and not preload them in non-supporting >>>>>>>> ones. >>>>>>>> "latest variant" - preload currently doesn't have support for >>>>>>>> "don't load this resource if you do support this feature" semantics. >>>>>>>> That >>>>>>>> means that you could use preload to load the most common or latest >>>>>>>> supported feature (e.g. variable fonts), but won't be able to use it to >>>>>>>> preload a different variant in browsers that don't support that >>>>>>>> feature. >>>>>>>> "type attribute" - >>>>>>>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-type >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 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 think it may be interesting to revamp content negotiation and >>>>>>>> base it on Client Hints, especially as `Accept` based headers are >>>>>>>> getting >>>>>>>> longer and longer. >>>>>>>> At the same time, `Accept` based negotiation is still very much a >>>>>>>> thing, and we shouldn't leave it aside. >>>>>>>> Also see https://github.com/w3c/woff/issues/2 >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> One of the biggest mistakes with webp adoption (IMO) was that new >>>>>>>> features were added to the format without changing its MIME type. That >>>>>>>> resulted in deployment issues (e.g. with old Android that only >>>>>>>> supported >>>>>>>> part of the features), forcing image CDNs to fallback to UA sniffing >>>>>>>> and >>>>>>>> other inaccurate methods. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> At this point, the "supports <technology>" syntax is something >>>>>>>>> that's defined in the spec and has been through spec discussions >>>>>>>>> already >>>>>>>>> and serves as one way for COLRv1 feature detection. It's something >>>>>>>>> that's >>>>>>>>> immediately implementable and doable right now to unblock feature >>>>>>>>> detection >>>>>>>>> for this new format. >>>>>>>>> >>>>>>>>> Developing such a useful new way of content negotiation for font >>>>>>>>> formats at the request/header level would be a longer specification >>>>>>>>> process >>>>>>>>> worthwhile starting. >>>>>>>>> >>>>>>>>> As we have requests for feature detection for COLRv1 if possible, >>>>>>>>> I would prefer not to block on that for shipping COLRv1 color fonts. >>>>>>>>> >>>>>>>>> Dominik >>>>>>>>> >>>>>>>>> On Fri, Jun 18, 2021 at 4:57 PM Dominik Röttsches < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Contact [email protected] >>>>>>>>>>> >>>>>>>>>>> Specification >>>>>>>>>>> https://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 >>>>>>>>>>> >>>>>>>>>> >>>>>>> I think this can benefit from a TAG review. >>>>>>> Resolution here seems like something that would impact issues on >>>>>>> preload <https://github.com/w3c/preload/issues/118>, fonts >>>>>>> <https://github.com/w3c/woff/issues/2> as well as content >>>>>>> negotiation solutions. That doesn't seem like something the CSSWG can >>>>>>> decide on unilaterally. >>>>>>> I'd love for the TAG to weigh in and decide if format features is >>>>>>> something that needs to be expressed as a variation of MIME types or on >>>>>>> a >>>>>>> completely separate dimension. If it's the latter, we need to see how we >>>>>>> integrate that separate dimension to preload (`supports` attribute?) >>>>>>> and to >>>>>>> the Accept header (or an alternative Client Hints based solution). >>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>> >> I think it'd make sense to ask for explicit signals from both Mozilla and >> Apple: bit.ly/blink-signals >> >> >>>>>>>>>>> >>>>>>>>>>> Web developers: Positive >>>>>>>>>>> >>>>>>>>>> >> Any links to artifacts of positive developer opinion? >> >> >>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>> >> I'm assuming it will be tested before shipping. Is that a correct >> assumption? >> >> >>> >>>>>>>>>>> >>>>>>>>>>> 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 [email protected]. >>>>>>>>>>> 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 >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBvJEc2pa1_pRWBSEktxHSEz_SnwjSyETVdoqpS_MXT1Gg%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/e5a7290d-4897-42fe-a069-db7581dc89f9n%40chromium.org >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e5a7290d-4897-42fe-a069-db7581dc89f9n%40chromium.org?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/CAN6muBuDiEKm-_bh%2BPza_Y40RkFJuN0xrDr4E9gJXmQ2W1sTkQ%40mail.gmail.com.
