Question about background: transparent

[Rhino]

I've been updating some CSS today and got one odd error from the validator
at http://jigsaw.w3.org/css-validator/. Every time I had 'background:
transparent;' (or background-color: transparent;) associated with a
selector, it gave me this error message:

Line : 30 (Level : 1) You have no background-color with your color :
#navlist li a

Here's the CSS fragment that it doesn't like:

#navlist li a {
color : #ffffff;
background-color : transparent;
text-decoration : none;
display : block;
}

The error went away when I changed the value to "inherit" or to a specific
color, like "#ffffff". According to the CSS reference I use, "transparen t"
is a perfectly acceptable value for "background " and "background-color". Any
idea why I am getting the error?
--
Rhino

[Alan J. Flavell]

On Fri, 18 Nov 2005, Rhino wrote:

I've been updating some CSS today and got one odd error from the
validator at http://jigsaw.w3.org/css-validator/. Every time I had
'background: transparent;' (or background-color: transparent;)
associated with a selector, it gave me this error message:

Line : 30 (Level : 1) You have no background-color with your color :

It's not an error, it's a warning, and has been discussed here quite
recently. I'd suggest reading previous discussions for a fuller
explanation.

In brief, you run a risk that your text colour will not contrast with
whatever background colour emerges from the cascade for the underlying
element that you're allowing to shine through. It's safer to define
the colour explicitly. You have to weigh up the issues and decide.

[Rhino]

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote in message
news:Pi******** *************** ******@ppepc56. ph.gla.ac.uk...

On Fri, 18 Nov 2005, Rhino wrote:

I've been updating some CSS today and got one odd error from the
validator at http://jigsaw.w3.org/css-validator/. Every time I had
'background: transparent;' (or background-color: transparent;)
associated with a selector, it gave me this error message:

Line : 30 (Level : 1) You have no background-color with your color :
It's not an error, it's a warning, and has been discussed here quite
recently.

Sorry, you're right. I misspoke; it is indeed a warning.
I'd suggest reading previous discussions for a fuller
explanation.
Thanks, I'll have a look through the archives....
In brief, you run a risk that your text colour will not contrast with
whatever background colour emerges from the cascade for the underlying
element that you're allowing to shine through. It's safer to define
the colour explicitly. You have to weigh up the issues and decide.

Is inherit a reasonable value to use or must I set a specific colour?

Rhino

[Arne]

Once upon a time *Rhino* wrote:

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote in message
news:Pi******** *************** ******@ppepc56. ph.gla.ac.uk...

In brief, you run a risk that your text colour will not contrast with
whatever background colour emerges from the cascade for the underlying
element that you're allowing to shine through. It's safer to define
the colour explicitly. You have to weigh up the issues and decide.

Is inherit a reasonable value to use or must I set a specific colour?

If it's resonable, depends on the color you have set for the parent
block (e.g. body).

If you have no background color (or transparent) the users browser may
use a default color that makes the content invisible. With inherit the
user mostly will see the color that are inherited from a parent block
and hopefully also the content.

But the warning only tells you the possibilities with transparent (or
no color), it's up to you to decide if it's important or not.

--
/Arne

Now ignoring all top posters
* How to post: http://www.cs.tut.fi/~jkorpela/usenet/brox.html
-------------------------------------------------------------

[Alan J. Flavell]

On Fri, 18 Nov 2005, Rhino wrote:

In brief, you run a risk that your text colour will not contrast with
whatever background colour emerges from the cascade for the underlying
element that you're allowing to shine through. It's safer to define
the colour explicitly. You have to weigh up the issues and decide.

Is inherit a reasonable value to use or must I set a specific colour?

Both 'transparent' and 'inherit' rely on getting something appropriate
from the result of the cascade at a different level.

In the wider practical context, one has to consider the results of
cascading with other stylesheets - some of which might not be under
your control, e.g a user stylesheet, or a corporate stylesheet if your
company insists on one - and also possible browser bugs.

If every cascaded stylesheet follows the guideline that every CSS rule
should explicitly specify either text colour *and* background colour,
or neither, then the possibilities for problems are much reduced.
But this is a guideline, not a fixed rule. What you're getting from
the validator is, after all, a warning, not an error.

But now I'm just repeating the earlier discussion in other words, so
I'll stop.

[Jukka K. Korpela]

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote:

Both 'transparent' and 'inherit' rely on getting something appropriate
from the result of the cascade at a different level.

Thus, 'inherit' is no real improvement over 'transparent', especially since
'inherit' isn't even supported by IE. It's a pity that people use tools like
the "CSS Validator" to get some mystic "approval" and complain about
reasonable warnings or shut them down by making useless or worse than useless
changes to their style sheets.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Rhino]

"Jukka K. Korpela" <jk******@cs.tu t.fi> wrote in message
news:Xn******** *************** ******@193.229. 4.246...

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote:

Both 'transparent' and 'inherit' rely on getting something appropriate
from the result of the cascade at a different level.
Thus, 'inherit' is no real improvement over 'transparent', especially
since
'inherit' isn't even supported by IE.

Really? It works fine for me in IE6, at least to the extent that it makes
the warning go away and doesn't mess up my pages. Mind you, that may be more
luck than good coding on my part :-)
It's a pity that people use tools like
the "CSS Validator" to get some mystic "approval" and complain about
reasonable warnings or shut them down by making useless or worse than
useless
changes to their style sheets.

I assume you are generalizing, and not just talking about me :-)

Nevertheless, let me say that I found the warning less than clear and
primarily wanted to understand what it was saying and what it implied for
the design of my style sheets. I wasn't primarily trying to get approval or
prevent reasonable warnings. I find some of the messages produced by the CSS
validator to be fairly cryptic: making them clearer and/or linking them to
tutorials to explain the broader issues raised by the messages would go a
long way to helping me write better CSS. But I don't have the expertise to
do this and I don't have the authority to order anyone else to do it so the
best I can do is try to understand what's going on :-)

There's another aspect to this that no one has mentioned.

If I have any halfways substantial number of selectors in my CSS, I might
state the same colour combination for color/background-color quite a few
times. That means that if I want to change that color, I have to change it
in many places. If I use some kind of "change all" command in my editor,
that is not too big a problem but if I change the instances manually, it is
very easy to miss one or two instances of the colour, which can cause some
confusion.

Now, if CSS provided variables, like programming languages do, that would
make life a lot easier. For instance, I would like to be able to do
something like this:

myBackgroundCol or = #0000cc;
myTextColor = #ffff66;

p {
background-color: myBackgroundCol or;
color: myTextColor;
}
td {
background-color: myBackgroundCol or;
color: myTextColor;
}

etc.

Then, changing the background-color would simply be a matter of changing it
once where the variables are defined, even if your editor didn't have a
"change all" feature.

Has anyone heard if there are plans to provide this sort of variable in
future version of CSS? I'm definitely not holding on breath on this being
provided, just curious to know if it is "in the works".

Rhino

[Alan J. Flavell]

On Sat, 19 Nov 2005, Rhino wrote:

Nevertheless, let me say that I found the warning less than clear
As I said, it's been discussed here recently

http://groups.google.co.uk/group/com...4de9f7774fe56a

Note that where the contributor says "known bug" he's referring to the
fact that the validator previously *didn't* issue a warning for
"transparen t". Maybe it should issue one for "inherit" too (except
where both text colour and background colour are defined as
"inherit").

There's a brief mention in the FAQ

http://www.websitedev.de/css/validator-faq#color

which however doesn't mention the implications of using transparent
or inherit, as such.

Note that transparent is the default. Specifying transparent has
similar implications to not specifying anything; the difference is in
terms of the cascade, in that the default has a different cascading
priority than an explicit specification of transparent. But the
outcome is still uncertain, if you're not in sole control of the other
stylesheets with which you are cascading - and taking good care never
to get the cascade wrong, despite browser bugs ;-{
Now, if CSS provided variables, like programming languages do, that
would make life a lot easier.

I'd advise you to accept that it doesn't, and isn't going to.

There's nothing stopping you from devising your own source language,
based on any kind of preprocessor which appeals to you, and pass that
through the preprocessor as part of your publish-to-web procedure
(using "make" to manage source files is a clever way to organise
that).

There are ways to make the preprocessing happen on the web server, at
the time the web pages are accessed, but unless you're very careful
with cacheability issues that can have unfortunate consequences. It's
safer to use a preprocessor, I would say.

[Rhino]

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote in message
news:Pi******** *************** ********@ppepc5 6.ph.gla.ac.uk. ..

On Sat, 19 Nov 2005, Rhino wrote:

Nevertheless, let me say that I found the warning less than clear

As I said, it's been discussed here recently

http://groups.google.co.uk/group/com...4de9f7774fe56a

Note that where the contributor says "known bug" he's referring to the
fact that the validator previously *didn't* issue a warning for
"transparen t". Maybe it should issue one for "inherit" too (except
where both text colour and background colour are defined as
"inherit").

There's a brief mention in the FAQ

http://www.websitedev.de/css/validator-faq#color

which however doesn't mention the implications of using transparent
or inherit, as such.

Note that transparent is the default. Specifying transparent has
similar implications to not specifying anything; the difference is in
terms of the cascade, in that the default has a different cascading
priority than an explicit specification of transparent. But the
outcome is still uncertain, if you're not in sole control of the other
stylesheets with which you are cascading - and taking good care never
to get the cascade wrong, despite browser bugs ;-{

Now, if CSS provided variables, like programming languages do, that
would make life a lot easier.

I'd advise you to accept that it doesn't, and isn't going to.

There's nothing stopping you from devising your own source language,
based on any kind of preprocessor which appeals to you, and pass that
through the preprocessor as part of your publish-to-web procedure
(using "make" to manage source files is a clever way to organise
that).

There are ways to make the preprocessing happen on the web server, at
the time the web pages are accessed, but unless you're very careful
with cacheability issues that can have unfortunate consequences. It's
safer to use a preprocessor, I would say.

Or use an editor that has a "change all" feature to change all occurrences
of a given colour quickly and easily :-)

I certainly don't want to tackle a preprocessor simply so that I can give
myself variables; I don't do nearly enough CSS to justify that. I was just
wondering if that functionality might come to CSS on its own at some point,
although I certainly didn't expect that it would.

Thanks to all who responded on this thread; it was quite educational for me!

Rhino

[Alan J. Flavell]

On Sat, 19 Nov 2005, Rhino wrote:

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote in message
[much quotage snipped...]

It's safer to use a preprocessor, I would say.

Or use an editor that has a "change all" feature to change all
occurrences of a given colour quickly and easily :-)

I certainly don't want to tackle a preprocessor simply so that I can
give myself variables;

But your "use an editor" proposal is also a form of preprocessor!
(Just has more possibilities of screwing things up by replacing things
that matched only by coincidence - especially if you're doing it
interactively and replacing the original source...)
I don't do nearly enough CSS to justify that.

Maybe you have something much more comprehensive in mind as a
preprocessor. But it's an idea that can be applied at almost any
level of complexity, from a simple match-and-replace to something
much more complex, whatever you're comfortable with.

cheers