Re: [csswg-drafts] [css-pseudo] defaulting ‘color’ in :root highlights (#6774)

@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](https://crrev.com/c/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](https://drafts.csswg.org/css-pseudo-4/#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](https://drafts.csswg.org/css-cascade-5/#inherited-property)).”
* [css-cascade-4 #defaulting](https://drafts.csswg.org/css-cascade-4/#defaulting): “[Inherited properties](https://drafts.csswg.org/css-cascade-4/#inherited-property) ***draw their defaults*** from ***[the corresponding highlight of]*** their parent element ***through [inheritance](https://drafts.csswg.org/css-cascade-4/#inheritance)*** [by analogy with the text above]; all other properties take their [initial value](https://drafts.csswg.org/css-cascade-4/#initial-value).”
* [css-cascade-4 #inheriting](https://drafts.csswg.org/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](https://drafts.csswg.org/css-cascade-4/#inherited-value) ***is the [initial value](https://drafts.csswg.org/css-cascade-4/#initial-value)*** of the property.”
    * [css-cascade-4 #inheriting](https://drafts.csswg.org/css-cascade-4/#inheriting) also says “[Pseudo-elements](https://drafts.csswg.org/selectors-4/#pseudo-element) 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](https://drafts.csswg.org/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](https://bucket.daz.cat/work/igalia/0/39.html)).
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. Under this option, ‘initial’ and ‘inherit’ and ‘unset’ would still mean ‘CanvasText’ at the root.

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 a strong opinion on what would work best… maybe @mrego or @andruud can comment?

-- 
GitHub Notification of comment by delan
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6774#issuecomment-1083055006 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 30 March 2022 12:04:25 UTC