LGTM2 On Fri, Sep 2, 2022 at 10:20 AM Alex Russell <slightly...@chromium.org> wrote:
> Hey Dominik, > > Thanks for getting back to me, the detail on the syntax, and for the link > to the explainer. Thanks also for correcting me regarding the TAG review. I > feel much better about the proposal as a result of all of this detail. > > On the CSS WG aspects, if features are developed w/ epxlainers like this, > as long as we're going first, it might make sense to use OT to road-test > them with developers, but I won't stand on it here as the explainer is > clear and, presumably, developers will weigh in with their support. > > LGTM > > Best, > > Alex > > On Friday, September 2, 2022 at 6:28:21 AM UTC-7 dr...@google.com wrote: > >> 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/d49673b0-57c6-4cc3-ae75-7169c4c380f5n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d49673b0-57c6-4cc3-ae75-7169c4c380f5n%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_jfTwmC1sq8wFd6jN-b%3Duxn9TJDRtrABgdiF24Of90Qw%40mail.gmail.com.
