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

Visit on Github.

Opened Mar 14, 2022

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.

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.

Discussions

Comment by @drott Mar 15, 2022 (See Github)

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.

Comment by @yisibl Mar 16, 2022 (See Github)

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.

Comment by @drott Mar 16, 2022 (See Github)

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.

Comment by @yisibl Mar 16, 2022 (See Github)

@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

Comment by @svgeesus Mar 16, 2022 (See Github)

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.

Comment by @svgeesus Apr 14, 2022 (See Github)

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

Comment by @LeaVerou Apr 18, 2022 (See Github)

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;
}
Comment by @yisibl Apr 18, 2022 (See Github)

@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?

Comment by @litherum Apr 18, 2022 (See Github)

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.

Discussed Apr 25, 2022 (See Github)

Lea: override colors does/does not support var references... discussion in CSS WG ... no consensus. Some clunky syntax... but reasonable response. Happy with that reasoning... the issues with references will be solved in a diffferent spec...

Peter: microsoft did somehting with --color ... custom properties?

Lea: no they are not defining custom properties... author defined...

Dan: Implementation status? Looks good from chrome status... Shipping in 101.

Lea: shipped in 15.4 Safari

Dan: looks good from a multi-stakeholder pov.

Dan: Shall we give it a thumbs up?

Peter: in the explainer ... custom colors ... multiple fonts being used within an element... can you reuse that overridden colors identifier? font palette value... keyed to the font?

Peter I can raise this issue in CSS wg - don't think it's architectural.

Dan: then I suggest we close with satisfied.

so mote it be

Peter: will write comment

(dug more throught the spec and answered my question, no issue)

Comment by @plinss Apr 25, 2022 (See Github)

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