Closed drott closed 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.
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.
In the current spec,
override-colors
does not supportvar()
, 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
.
@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
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.
@plinss the explainer PR was merged, the explainer is here
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;
}
@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?
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.
We took a look at this today and don't have any concerns. Looks good to us. Thanks for flying TAG.
Braw mornin' TAG!
Review Request
I'm requesting a TAG review of
font-palette
and@font-palette-values
and intent to inform the TAG about the existing plans to ship this feature in two engines, see below.Further details:
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.