transparency as color Options

[jimlongo]

Is transparent an acceptable color?
Documents seem to say yes, but validators seem to say no.


If so is this acceptable
background: transparent none;

thanks,
jim

[pandy]

Is transparent an acceptable color?
Documents seem to say yes, but validators seem to say no.

Well, depends on what you mean. It isn't an acceptable value for the color property. But it is for the background-color property.
http://www.w3.org/TR/REC-CSS2/colors.html#propdef-color
http://www.w3.org/TR/REC-CSS2/colors.html#...ackground-color

If so is this acceptable
background: transparent none;

Yes, but possibly it's redundant.
"The 'background' property first sets all the individual background properties to their initial values, then assigns explicit values given in the declaration"
http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background

Both 'transparent' and 'none' are the initial values for their respective properties. Neither property is inherited either. If you want to overlay the background color or background image of a parent element, transparent and none will get you nowhere. You have to use a real color or an image.

On the other hand, if you want it just to follow the rule that all colors should be accompanies by a background color and vice versa, it makes sense but you only need one value since the other will be implied (see the quote above). 'background: none' is common.

Did you have to use such an intricate example?

[Darin McGrew]

Of course, specifying a transparent background doesn't help prevent conflicts between colors specified in one style sheet and backgrounds specified in another.

[jimlongo]

I ask only because the validators insist on a background color whenever a color is present. I understand the reason behind that.
In my menu any background color overrides the background image that the box contains. So I had background: none; which worked fine, but the validators didn't approve.

[pandy]

That warning has changed a lot during the years. It was even gone a few years. Remember, it's a warning, not an error.

What Darin hints at is this. If, for example, a user style sheet has this rule:

body { background: red; color: black }

Then you go:

p.note { color: red; background: transparent }

See? You'll end up with red text on a red background.

The common recommendation seems to be to use 'inherit' instead. I don't see how that makes much difference though. The only totally safe option seems to be to use an actual color.

[jimlongo]

On a site like this http://www.wanlesstennis.com/ a background color in the hover elements will totally screw up the background image in the menu box.

How do you overcome that? When you specify a color for the links - then the validator demands a color for the background.

That's where i use backround:none; - any background color will interfere with the background.

[Darin McGrew]

On a site like this http://www.wanlesstennis.com/ a background color in the hover elements will totally screw up the background image in the menu box.

How do you overcome that?

In practice, people seem to ignore the issue and either not specify a background, or specify a transparent/inherited background.

In theory, I suppose you could specify a background image for the links that is positioned the same way as the main background image. But as the Complexspiral Demo at css/edge demonstrates, MSIE doesn't support the necessary CSS.

[pandy]

Not if you use the same background color or background image, whatever it is, as the parent element uses.

I don't know. I don't do this myself more than occationally. I contemplate doing it though. I'm also brooding over why inherit is supposed to be better than transparent.

[Christian J]

I think it's a good rule of thumb to use both color and background, but it shouldn't be taken as gospel. E.g., if text spills out of its container, the container's background becomes moot.

In simple cases it should be enough to know which parent element color that affects which ancestor, if necessary by adding comments in the style sheet:

CODE

p {
color: #000;
background: #fff url(image.jpg);
}

p strong {
color: #f00;
background: transparent; /* image.jpg from P */
}

What one needs to watch out for is situations like these:

* The background is an image with no background-color, but the browser doesn't show images.

* Color and background are specified with different kinds of selectors, but the browser only understand one of them. Ditto for different ways to link, embed or import style sheets.

-----------------

BTW, what is going on here? According to http://www.w3.org/TR/CSS21/colors.html#propdef-background "background" is not inherited, but Opera and Firefox still add a new copy of the background-image behind STRONG:

CODE

p {
color: #000;
background: #0f0 url(dog.jpg);
}

p strong {
color: #f00;
background: inherit;
}

[pandy]

But you tell it to inherit.

[Christian J]

But you tell it to inherit.

Yes but if it's not supposed to inherit, shouldn't it ignore my incorrect(?) CSS rule?

[Darin McGrew]

Yes but if it's not supposed to inherit, shouldn't it ignore my incorrect(?) CSS rule?

The "Inherited: no" line means that it is not inherited by default. Specifying the value "inherit" overrides that.

[Christian J]

Of course! Now I even notice "inherit" is included among the values.

[pandy]

Yeah, you can do the same with border and other properties that aren't normally inherited.