-
Notifications
You must be signed in to change notification settings - Fork 756
Description
Colors in CSS are resolved within a context. For example:
<div style="color-scheme: dark; color: text;">Hello, World!</div>
<div style="color-scheme: light; color: text;">Hello, World!</div>
In this example, the meaning of text is different for the two different elements, because of some other property: color-scheme. A similar phenomenon occurs for the currentColor keyword and the color property.
What is the context that colors in @font-palette-values are resolved within?
I think we have 3 options:
- Disable these context-sensitive color keywords outright.
override-color: 0 text;would be a parse error. - Resolve the color keywords in the context of the root element.
- Resolve the color keywords in the context of the element referencing the
@font-palette-valuesrule.
Option 3 is significantly more difficult than the others to implement, because it means that a single @font-palette-values rule will behave differently when applied to different elements, even if the two different elements have the same values for font-family and font-palette. It's particularly difficult in WebKit, where our text engine is divorced from the CSS engine - it would entail treating color, color-scheme, and anything else that can affect color resolution as "font properties" which get threaded throughout the text engine. This also means that our font caches will have to be sensitive to a bunch of (seemingly unrelated) color properties - and even if the cache hit rate won't decrease, simply the act of computing hashes and comparisons of bigger objects has real cost.
Option 1 would be the best, I think, at least to start with, until authors specifically ask for this feature. I can see how it might be useful to have your palette update based on the document, but I think this functionality would essentially be a niche within a niche. We can always add in additional flexibility later, if authors ask for it.