Help - Search - Members - Calendar
Full Version: transparency as color
HTMLHelp Forums > Web Authoring > Cascading Style Sheets
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
QUOTE(jimlongo @ Oct 3 2006, 12:36 AM) *

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. tongue.gif
http://www.w3.org/TR/REC-CSS2/colors.html#propdef-color
http://www.w3.org/TR/REC-CSS2/colors.html#...ackground-color

QUOTE

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? laugh.gif
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
QUOTE(jimlongo @ Oct 2 2006, 06:09 PM) *
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. huh.gif
Christian J
QUOTE(pandy @ Oct 3 2006, 05:50 PM) *

But you tell it to inherit. huh.gif


Yes but if it's not supposed to inherit, shouldn't it ignore my incorrect(?) CSS rule?
Darin McGrew
QUOTE(Christian J @ Oct 3 2006, 10:50 AM) *
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. blush.gif
pandy
Yeah, you can do the same with border and other properties that aren't normally inherited.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.