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 <https://groups.google.com/a/chromium.org/g/blink-dev/c/bCA9H3eaO3s/m/bjOhM6MLFQAJ>, 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 > 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/d8ed9ab7-0b38-4d43-9838-93f1c05db63fn%40chromium.org.
