W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

Re: [csswg-drafts] [css-color-5] Add `currentBackgroundColor` Variable (#5292)

From: Xidorn Quan via GitHub <sysbot+gh@w3.org>
Date: Sun, 02 Aug 2020 07:12:04 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-667638583-1596352323-sysbot+gh@w3.org>
If we introduce a `current-background-color` (let's not repeat the mistake of `currentColor`), it needs to be decided whether this new keyword should be preserved in computed value like `currentcolor`, or get replaced by a fixed value like other named colors.

If it's made a computed-value time keyword like `currentcolor`, and it's used in `color`, I suspect that it would very likely cause pretty confusing result to authors, as all the descendants of an element would likely have a text color derived from `transparent` background, because they all read from background color of the current element if `color` inherits the `current-background-color` keyword rather than the color itself. Depending on how we define style of text, this could potentially be meaningless at all.

Additionally, we currently have `currentcolor` be a computed-value time keyword, but when specified on `color` property, it becomes a specified-value time keyword, i.e. it's replaced by the `color` value of its parent. Adding `current-background-color` makes it more complicated.

If we preserve `current-background-color` as computed-value time keyword for `color`, we inherently preserve `currentcolor` as keyword on `color`, and at the worst case we may need to climb the DOM tree all the way up to the root just for resolving a color for rendering. This, along with the issue above indicates that we may want `current-background-color` to at least be a specified-value time keyword for `color` property.

On the other hand, if it's made a specified-value time keyword like other named colors, and it gets replaced by the color specified by `background-color` on the element when producing computed value, it might also cause confusion as it would behave differently from `currentcolor` on transition, e.g. if you are transitioning `border-color` from `red` to `currentcolor`, while also transitioning `color` from `green` to `blue`, then the used value of `border-color` would be a mixed of the three colors, which is only possible when it's a computed-value time keyword.

It feels like that having `current-background-color` being a computed-value time keyword, but get resolved in `color` and `background-color` properties would likely be the most sensible approach forward. This would make `background-color` a dependency for `color` property in computation, but that's probably not the end of the world.

I have to admit that I started this comment with being strongly against this idea as I felt it would be adding unreasonable amount of complexity to implementations. But having all the above written, I now think it's probably manageable. I would still be against from implementer's point of view, as it still feels like some complexity more than its worth, but less strongly.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 2 August 2020 07:12:11 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC