- From: Xidorn Quan via GitHub <sysbot+gh@w3.org>
- Date: Sun, 02 Aug 2020 07:12:04 +0000
- To: public-css-archive@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