FYI Review of CSS Fonts 4 `font-palette`and `@font-palette-values`

drott commented 2 years ago

Braw mornin' TAG!

Review Request

I'm requesting a TAG review of font-paletteand @font-palette-values and intent to inform the TAG about the existing plans to ship this feature in two engines, see below.

Explainer¹: https://github.com/w3c/csswg-drafts/pull/7138 & https://github.com/drott/csswg-drafts/blob/paletteExplainer/css-fonts-4/palette-explainer.md
Specification URL: https://www.w3.org/TR/css-fonts-4/#font-palette-prop
Tests: https://wpt.fyi/results/css/css-fonts?label=master&label=experimental&aligned&q=palette
User research:
Security and Privacy self-review²: https://www.w3.org/TR/css-fonts-4/#security
Primary contacts (and their relationship to the specification):
- @drott, @litherum, @svgeesus
Organization(s)/project(s) driving the specification: Google, Apple
Key pieces of existing multi-stakeholder review or discussion of this specification:
- Previous issues (non-exhaustive list) that @litherum, @drott and @svgeesus discussed while WebKit and Blink were implementing this.
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):

Further details:

✅ I have reviewed the TAG's Web Platform Design Principles
The group where the work on this specification is currently being done: CSS WG
The group where standardization of this work is intended to be done: CSS WG
Major unresolved issues with or opposition to this specification: None that I knew off.
This work is being funded by: Google, Apple

You should also know that...

Real word example

There's a polyfilled example of custom palette usage at https://underware.nl/fonts/plakato/features/color/ where font foundry Underware hosts their Plakato Color Grade experiment.

Shipping intentions

Safari publishes this feature in their Safari 15.4 Beta Release Notes, indicating a plan to ship this soon. For Blink @drott posted an intent-to ship as well. So two engines are planning to ship this feature in the near future.

Feedback Channel

We'd prefer the TAG provide feedback as comments on this issue.

drott commented 2 years ago

Preliminary positive feedback towards a "worth prototyping" standards position from Mozilla as well from @jfkthame in https://github.com/mozilla/standards-positions/issues/617#issuecomment-1068042019 - Thank you, Jonathan.

Update: Now finalized as "worth prototyping" in that issue.

yisibl commented 2 years ago

In the current spec, override-colors does not support var(), which affects the developer's actual experience, and we have to define a lot of duplicate colors.

drott commented 2 years ago

In the current spec, override-colors does not support var(), which affects the developer's actual experience, and we have to define a lot of duplicate colors.

Why not? From https://www.w3.org/TR/css-fonts-4/#font-palette-values

Functions such as calc(), var(), and env() are valid within the braces of a @font-palette-values rule. They are evaluated within the context of the root element. Relative units are also evaluated within the context of the root element.

I interpret to mean var() being valid in override-colors.

yisibl commented 2 years ago

@drott I misunderstood, it's just that current browsers don't implement var() in override-colors? Let's continue the discussion here: https://github.com/w3c/csswg-drafts/issues/6931

svgeesus commented 2 years ago

The current specification allows var() in override-colors. https://github.com/w3c/csswg-drafts/issues/6931 proposes disallowing this, so that there is no dependency on the root element's computed style. There is no consensus on whether and how to restrict it.

svgeesus commented 2 years ago

@plinss the explainer PR was merged, the explainer is here

LeaVerou commented 2 years ago

Is it intentional that authors still need to create an @font-palette-values rule to use a built-in palette?

p::first-letter {
    font: 2.9em/.8 "Fancy color font";
    float: left;
    font-palette: --lilac-blossom;
}

@font-palette-values --lilac-blossom {
    font-family: "Fancy color font";
    base-palette: 7;
}

instead of just:

p::first-letter {
    font: 2.9em/.8 "Fancy color font";
    float: left;
    font-palette: 7;
}

yisibl commented 2 years ago

@LeaVerou I see that the current specification can only change the font-palette using the former approach.

Syntactically speaking, font-palette: 7 is an invalid value.

font-palette: normal | light | dark | <palette-identifier> <palette-identifier> is parsed as a <dashed-ident>.

As a CSS creator, I would definitely like to be able to modify the font-palette straight away. I wonder if there are some difficulties with this in the spec or browser implementation?

litherum commented 2 years ago

Is it intentional that authors still need to create an @font-palette-values rule to use a built-in palette?

Yes, because of font fallback. Authors don’t actually know which font will be used. If their desired font doesn’t load and the fallback font also happens to be a color font, palette 7 will be something totally arbitrary. At least with the at-rule, the fallback will be the default palette.

plinss commented 2 years ago

We took a look at this today and don't have any concerns. Looks good to us. Thanks for flying TAG.

w3ctag / design-reviews