[css-color-4] backgroundColor

[frivoal]

Just as we have currentColor, having backgroundColor (or background-color) would be useful when you're doing effects that depend on the background color, but you don't know what it is (for example when the background color changes in various parts of the document).

Here's an example which could be solved by having that keyword:

http://jsbin.com/detezeb/edit?css,output

The definition, which would parallel that of currentColor, would be something like:

The keyword ''backgroundColor'' takes its value from the value of the 'background-color' property on the same element. This happens at used-value time, which means that if the value is inherited, it’s inherited as ''backgroundColor'', not as the value of the color property, so descendants will use their own color property to resolve it.

If ''backgroundColor' is used as the value of the background-color property, it instead takes its value from the value of the background-color property on the parent element, or ''transparent'' if there is no parent element.

[SebastianZ]

I guess for consistency and clarity it should be currentBackgroundColor, though that's quite long as a keyword.

Sebastian

[frivoal]

I don't care all that stongly what it's called: currentBackgroundColor, currentBackground, backgroundColor, bgColor, same things with hyphens... All good to me.

[upsuper]

FWIW, your example actually doesn't match what you were expecting, because background-color is not inherited by default, and thus backgroundColor in your example is actually transparent. (Even if it is inherited by default, your background would override that value as well.) This can be fixed by adding background-color: inherited explicitly, though.

I doubt its usefulness. Is there any other usecase? In this example, things would not work if the background underneath is an image, or even a gradient. And this simple usecase can easily be achieved via a common variable. This very limited usecase doesn't look very convincing to me.

Also given that you made this mistake when you wrote the example (I'm not blaming you, but), I suspect this setting isn't as intuitive as it looks like, which would also be a problem.

[frivoal]

FWIW, your example actually doesn't match what you were expecting, because background-color is not inherited by default, and thus backgroundColor in your example is actually transparent. (Even if it is inherited by default, your background would override that value as well.) This can be fixed by adding background-color: inherited explicitly, though.

and

Also given that you made this mistake when you wrote the example (I'm not blaming you, but), I suspect this setting isn't as intuitive as it looks like, which would also be a problem.

I did explicitly set the background-color to currentBackground via the shorthand, so that it would be picked from the parent, so I think I did get that right.

[frivoal]

And this simple usecase can easily be achieved via a common variable.

Uses of currentColor can also be replaced by a variable. Yet people find it useful.

[upsuper]

Given that we now have text-fill-color (have we added that to CSSWG's spec?), I actually consider color as a pure builtin variable... So it's a variable :)

[upsuper]

And currentColor pre-exists CSS Variables, so this is something we are stuck with anyway.

[frivoal]

Is there any other usecase?

.ghost-text {
  text-shadow: 0 0 3px black;
  color: backgroundColor;
}

[upsuper]

This example makes me more worry about the complexity of adding it...

[fantasai]

Given Xidorn's reasoning in comment #4*, I'm inclined to agree with
closing this wontfix.

~fantasai

• GitHub conveniently doesn't put comment numbers in its email output...

[frivoal]

GitHub conveniently doesn't put comment numbers in its email output...

When you write #<some number>, github autolinks to the issue with that number, no the comment.

[frivoal]

Given Xidorn's reasoning in comment #???, I'm inclined to agree with closing this wontfix.

Which comment is that? This one #364 (comment) where he says it can be done with variables?

I agree that technically it can be. However, in the case I'm working on, this wouldn't be practical. On a large project, the people responsible for content and the people responsible for UX/UI/Design are often not the same. The kind of shadow effect I was setting up falls under the UX side of things. On the other hand, setting the background of something might be done by UX people, but just as often it might also be done on a semi ad-hoc manner by people in charge of the content. If the two cannot coordinate, or if the content was written first, and the UX people are trying to deal with it, they cannot retroactively replace colors that have been hardcoded into the content with variables which they can then reuse.

Concretely, what I am trying to do is to write an additional stylesheet for W3C documents (old and new), and use the shadow effect demoed here on a variety of potentially overflowing elements. But all sorts of specs have all sorts of custom background colors for various elements (notes, examples, warnings, various kinds of notices, IDL declarations, blockquotes, syntax highligthed code samples, non highlighted code samples, grammar definitions...), some shared across most of TR, many not. I cannot retroactively change these into variables, partly because the specs are frozen, partly because there's so many of them. This is what I ran into, but this is by no means unique to TR. If you were writing a theme for a blogging engine, you'd run into the same issue. Same thing If you were restyling MSDN or MDN or any large collection of documents.

In theory, you could use variables instead of the em unit if you were careful to set them up properly, but this would be a pain. Same thing for currentColor. We'd still want to have these even if variables had been invented earlier. I'd put backgroundColor in the same bucket. Less pressing than the first two, but still useful enough to expose IMO.

[upsuper]

I agree that your both usecases are valid, but I don't think using backgroundColor is the right path to get them, because

1. that doesn't work if the background is not a pure color
2. adding another color keyword which depends on other property adds much complexity to implementation (currentColor is already a thing no engine has implemented thoroughly yet, and it hasn't even been specced perfectly. You couldn't expect backgroundColor to be a trivial thing for engines to implement)

So it's neither simple nor useful enough.

I guess we may need some other new mechanism to address the usecases, but I have no idea what that would look like.

[tabatkins]

I agree with the naysayers here:

• background-color, being non-inheritable, is really unsuited for these kinds of things; you're limited solely to use-cases where you're reusing the background color on the element itself, not on any children
• background colors are often communicated via images, not background-color, which doesn't work at all here
• variables do exactly the same job, only better

I get that "just use variables" doesn't work very well if you're trying to do a hands-off refactor over the top of some existing styles, but that's not something we usually optimize for in CSS.

[frivoal]

Alright, I am sad that y'all don't like my problem, and I still think it would be cool, but fine, I'll accept that the implementation difficulty and design compromises are bad enough, and the use cases small enough, that this isn't going to work out.

Begrudgingly closing.