I think ::selection { background-color: <something>; color: currentColor; } (that is, the test-case above) should not change the color of the element that is selected.

It's a common way to implement selections that work well on both light and dark mode for example, by providing a semi-transparent background color...

I think ::selection { background-color: <something>; color: currentColor; } (that is, the test-case above) should not change the color of the element that is selected.

Under highlight inheritance, that would still be true — “currentColor on a highlight pseudo-element’s color property represents the color of the next highlight pseudo-element layer below” (#highlight-text). The test case in this issue is different, because there’s no color property in the ::selection rule.

Wait so color: currentcolor and color: inherit do two different things on highlights? That seems broken.

Yeah, for originating elements and the other pseudos (at least tree-abiding ones), color:currentColor just means color:inherit, but for highlights, color:currentColor jumps across to the same place in the next (active?) highlight tree (or originating tree).

The way I’ve made sense of it is that in both cases, color:currentColor effectively means “don’t change the color”. One is “don’t change the color in this child”, the other is “don’t change the color in this highlight”.

@megangardner

(summary for meeting)

Highlights used to only inherit from the originating element, but now they inherit from the parent’s highlight styles, creating separate “inheritance trees” for each highlight.

We previously resolved that the compat risk was acceptable (#2474), because the old behaviour wasn’t really useful or intuitive anyway, but there’s a new breakage that I don’t think we were aware of, and I just want to check if we’re still happy with the risk.

The CSS Working Group just discussed Compat risk for ::selection defaulting one color from originating element.

@emilio

emilio: I think the only issue is with the color property
emilio: all current impls store as computed color
emilio: otherwise need to go figure it out every time resolving a color for a given style
emilio: I think the spec doesn't reflect that

We’ve started implementing this in Blink, and we think we’ve found a workaround for this problem that doesn’t complicate things for non-highlight styles or slow down style resolution.

CL:3506351 leaves ‘color’ storage and resolved-color-returning functions like GetCurrentColor and VisitedDependentColor untouched, but adds an inherited flag for whether ‘color’ was ‘currentColor’. If the flag is true, the highlight painting code ignores the incorrectly-resolved ‘color’ in ComputedStyle and grabs it from the next layer below (currently originating, but soon this could be a highlight overlay). ‘currentColor’ is stored as itself for ‘background-color’, so for that, we check if the flag is set and the background is ‘currentColor’, and ignore accordingly.

gCS is not implemented yet, but we think it can be done similarly or even simpler, because we’re pretending that the given highlight is active for the whole element and all other highlights are inactive (#6818).

@fantasai

fantasai: I think the test is correct, actually, and paired cascading is also correct
fantasai: inheriting all the way up, should get currentColor, not black
fantasai: though I'm not sure the spec is clear about that

@frivoal

florian: Delan, can you point out to which bit of the spec made you think that you would go to black rather than originating element?
florian: wondering if it's ambiguous or wrong

I believed that ‘color’ would become ‘CanvasText’ (usually black) because of these spec texts (emphasis mine):

• #highlight-cascade: “When any supported property is not given a value by the cascade, its value is determined by inheritance from the corresponding highlight pseudo-element of its originating element’s parent element (regardless of whether that property is an inherited property).”
• css-cascade-4 #defaulting: “Inherited properties draw their defaults from [the corresponding highlight of] their parent element through inheritance [by analogy with the text above]; all other properties take their initial value.”
• css-cascade-4 #inheriting: “For [highlight pseudo-elements of] the root element [by analogy with the text above], which has no parent element, the inherited value is the initial value of the property.”
  • css-cascade-4 #inheriting also says “Pseudo-elements inherit according to the fictional tag sequence described for each pseudo-element.” but highlights have no fictional tag sequence, and I feel like those are non-normative anyway?
• css-color-4 #the-color-property: “Initial: CanvasText”

Have I missed something? If we want the specified value of a :root highlight’s ‘color’ to be ‘currentColor’, which I agree is reasonable, we should say so somehow. A few options come to mind:

1. For highlight pseudos, we redefine the initial value of ‘color’, from ‘CanvasText’ to ‘currentColor’. This would make ‘initial’ and ‘inherit’ and ‘unset’ also mean ‘currentColor’ at the root.
2. For highlight pseudos, we redefine the inherited value of ‘color’ at the root, from the initial value to ‘currentColor’. This would make ‘inherit’ and ‘unset’ also mean ‘currentColor’ at the root, though ‘initial’ would still mean ‘CanvasText’, just like how they work in pre-highlight inheritance impls (demo).
3. For highlight pseudos, we redefine defaulting for ‘color’ at the root, from using inheritance to ‘currentColor’. Under this option, ‘initial’ and ‘inherit’ and ‘unset’ would still mean ‘CanvasText’ at the root.
4. For highlight pseudos, we say that root highlights inherit all properties from the next highlight below. This would make ‘inherit’ and ‘unset’ also mean ‘currentColor’ at the root, though ‘initial’ would still mean ‘CanvasText’.

I don’t see how option 4 could work, because it would need to be the next active highlight below (making resolved styles entirely dependent on active highlights), and it would need to be the leaf node’s styles for that highlight (making the root styles dependent on descendant styles). Other than that, I don’t have any opinions on what’s best… maybe @mrego or @andruud can comment?

@emilio

emilio: I think the only issue is with the color property
emilio: all current impls store as computed color
emilio: otherwise need to go figure it out every time resolving a color for a given style
emilio: I think the spec doesn't reflect that

We’ve started implementing this in Blink, and we think we’ve found a workaround for this problem that doesn’t complicate things for non-highlight styles or slow down style resolution.

CL:3506351 leaves ‘color’ storage and resolved-color-returning functions like GetCurrentColor and VisitedDependentColor untouched, but adds an inherited flag for whether ‘color’ was ‘currentColor’. If the flag is true, the highlight painting code ignores the incorrectly-resolved ‘color’ in ComputedStyle and grabs it from the next layer below (currently originating, but soon this could be a highlight overlay). ‘currentColor’ is stored as itself for ‘background-color’, so for that, we check if the flag is set and the background is ‘currentColor’, and ignore accordingly.

Hmm, is that really enough? I'm not sure it can just be a flag, because currentColor can be interpolated with other colors, can't it? As in, what if I do color: color-mix(currentColor, ...) or other such things?

That is a bit unfortunate in general since it's a whack-a-mole and now all of the decoration code needs to be aware of this flag everywhere, right? So it can't really share much code with the rest of the painting code-paths.

I'm not sure it can just be a flag, because currentColor can be interpolated with other colors, can't it? As in, what if I do color: color-mix(currentColor, ...) or other such things?

Blink doesn’t support any advanced color features yet, but I think in that case we would still set the flag, indicating that ‘color’ is dependent on currentColor. Once we know what currentColor will be — for now, that means during paint — we call whichever function we normally call to resolve (and possibly mix) color values.

‘text-shadow’ might prove tricky because it’s a list of shadows, each with a color value, but I think either the current approach (flag for the whole property) or moving the flag into Color (for more granularity) could work. The former is probably faster for us right now, because unlike WebKit, our Color is still just a newtype for rgba32.

That is a bit unfortunate in general since it's a whack-a-mole and now all of the decoration code needs to be aware of this flag everywhere, right? So it can't really share much code with the rest of the painting code-paths.

Not really, in Blink, as most of the paint code lets the caller pass intermediate structs for text colors (TextPaintStyle) and decoration details (TextDecorationInfo, AppliedTextDecoration). The text fragment painter or highlight overlay painter decides what colors to fill those structs with (using helpers like HighlightPaintingStyle), but from there the logic is the same.

Blink doesn’t support any advanced color features yet, but I think in that case we would still set the flag, indicating that ‘color’ is dependent on currentColor. Once we know what currentColor will be — for now, that means during paint — we call whichever function we normally call to resolve (and possibly mix) color values.

But that means that you need to preserve the unmixed color in the computed style, which is what you want to avoid to begin with right? Anyways I'm not opposed to that but seems a bit tricky off-hand.

Blink doesn’t support any advanced color features yet, but I think in that case we would still set the flag, indicating that ‘color’ is dependent on currentColor. Once we know what currentColor will be — for now, that means during paint — we call whichever function we normally call to resolve (and possibly mix) color values.

But that means that you need to preserve the unmixed color in the computed style, which is what you want to avoid to begin with right? Anyways I'm not opposed to that but seems a bit tricky off-hand.

As animations are not allowed on highlight pseudos probably the only thing special thing would be color-mix, that's not supported in Chromium yet so we didn't have to deal with that in the initial implementation.

I agree it's going to be more tricky than just storing a flag, but it's still something possible to implement.
Giving how highlights inheritance works, and that we need to do something special with currentcolor I believe we have to accept this complexity to move forward.

Thanks @emilio! I think we should consider resolving with option 2 from my earlier comment:

2. For highlight pseudos, we redefine the inherited value of ‘color’ at the root, from the initial value to ‘currentColor’. This would make ‘inherit’ and ‘unset’ also mean ‘currentColor’ at the root, though ‘initial’ would still mean ‘CanvasText’, just like how they work in pre-highlight inheritance impls (demo).

The CSS Working Group just discussed Default color in :root highlight, and agreed to the following:

• RESOLVED: Go with Delan's option 2.

@emilio @fantasai re currentColor disappearing at computed value time, css-color-4 #resolving-other-colors says

The currentcolor keyword computes to itself.

which is why this rect is green, not red (demo)

<svg viewBox="0 0 300 150" xmlns="http://www.w3.org/2000/svg">
    <g><rect x="10" y="10" width="10" height="10" /></g>
    <style>
        g { color: red; fill: currentColor; }
        rect { color: green; fill: inherit; }
    </style>
</svg>

@delan yeah, my point is that that doesn't match how browsers work for the color property in particular.

I was going to point how even Chrome doesn't think the computed value is currentColor for the color property, but its computedStyleMap() is broken:

<span style="color: currentColor; background-color: currentColor"></span>

document.querySelector("span").computedStyleMap().get("color").toString() // rgb(0, 0, 0)
document.querySelector("span").computedStyleMap().get("background-color").toString() // rgb(0, 0, 0)

Per spec, both should be currentColor. In Firefox and pretty sure WebKit, the former would be black.

https://bugs.chromium.org/p/chromium/issues/detail?id=1338607 for the bug above.

#6665 makes the edits for this question.