(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. On Thursday, September 1, 2022 at 4:31:39 PM UTC+2 dr...@chromium.org wrote: > 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 > <https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md> > 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 <https://chromium-review.googlesource.com/c/chromium/src/+/3856267>. > > [...] and how you're expecting developers to use it would be helpful [...] >> > > The explainer lists 3 main use cases > <https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md#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 > <https://groups.google.com/a/chromium.org/g/blink-dev/c/bCA9H3eaO3s/m/pe7T3PFdAQAJ>. > > In the I2S then a TAG review was requested, *TAG review here* > <https://github.com/w3ctag/design-reviews/issues/666>. > The TAG suggested changes > <https://github.com/w3ctag/design-reviews/issues/666#issuecomment-901220221>, > 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 > <https://github.com/w3ctag/design-reviews/issues/666>, 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 > <https://bugzilla.mozilla.org/show_bug.cgi?id=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 > > On Wednesday, August 31, 2022 at 8:52:02 AM UTC-7 Philip Jägenstedt wrote: >> >>> 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 emailsdr...@chromium.org >>>>> >>>>> ExplainerNone >>>>> >>>> >>>> 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. >>> >> -- 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/79136cc1-2ec9-4da2-b6bf-b6e81d74b62bn%40chromium.org.
