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 <yoavwe...@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/CAN6muBtjyOn%3DzibFztkcsG4TG0xvi5WjJAFQ%2BSvsgHobr9po9Q%40mail.gmail.com.

Reply via email to