Unrequired LGTM4! Thanks Dominik for the explainer :) On Fri, Sep 2, 2022 at 9:00 PM Philip Jägenstedt <foo...@chromium.org> wrote:
> LGTM3 > > On Fri, Sep 2, 2022 at 7:48 PM Chris Harrelson <chris...@chromium.org> > wrote: > >> 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/CAL5BFfVn277fvBtc9NMStyrqHq%2BOtt7HXGJpj82R%3DUjKnCWVUg%40mail.gmail.com.
