- From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 May 2022 10:59:20 +0000
- To: public-css-archive@w3.org
> @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. 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. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6774#issuecomment-1114723441 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 May 2022 10:59:22 UTC