- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Nov 2020 17:44:21 +0000
- To: public-css-archive@w3.org
I'm seeing the core use-case here being "I want a well-established 'main color' for an element", and it happens that the nearest "significant" background-color usually carries that information. The use-case is very valuable! In SVG, the 'color' property ends up carrying that information, via the `currentcolor` keyword, because 'color' doesn't *do* anything in SVG *except* set that variable. But CSS uses 'color' *and* uses `currentcolor`, and you're looking for a different value. There have been a lot of objections to actually using 'background-color', for a combination of implementation and specification reasons; mainly, the "nearest significant background-color" seems difficult to specify and difficult to implement performantly. There's also a reasonable objection against the "just use a variable" suggestion; it solves all the specification/implementation issues, but loses the authoring convenience of hooking into already-used stuff. I don't think this is a knot we can untie, honestly; the use-cases are valuable, but I don't think they outweigh the downsides. But perhaps we could address the core problem more directly, and define an official "main-color" property that is solely used to define a new color keyword (with the same behavior as 'color'+`currentcolor`; the property inherits, the keyword computes to itself), effectively being a custom property+var() pair. This might solve the issue of "nobody can agree on the variable name to use", while still letting us avoid all the issues with trying to *infer* the color from bg-color? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5292#issuecomment-725564480 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 November 2020 17:44:23 UTC