Background in css gives warning

A

Adario

When I use the following:

body {background: #d4ecfb;}

The validator says:

Warnings
URI : file://localhost/main.css

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

It works but gives the warning. Any ideas?
 
B

Beauregard T. Shagnasty

Adario said:
When I use the following:

body {background: #d4ecfb;}

The validator says:

Warnings
URI : file://localhost/main.css

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

It works but gives the warning. Any ideas?

"You have no *color* with your background-color"

body {background: #d4ecfb; color: #000;}

[or whatever works and contrasts with #d4ecfb...]
 
E

Ed Mullen

Adario said:
When I use the following:

body {background: #d4ecfb;}

The validator says:

Warnings
URI : file://localhost/main.css

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

It works but gives the warning. Any ideas?

It is not invalid, it's just a warning. The point is that a user's
settings may specify either or both of background color and text color.
If you specify, for instance, only a bg color of black and the user
has an over-ride setting text color to black ... well. So the validator
is telling you of a potential usability problem, not invalid code.
 
N

Neredbojias

With neither quill nor qualm, Adario quothed:
When I use the following:

body {background: #d4ecfb;}

The validator says:

Warnings
URI : file://localhost/main.css

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

It works but gives the warning. Any ideas?

If you specify a color without a background-color or vice versa on any
element, the validator will give a warning. In some cases it's
ridiculous (-not all,) but the validator is the validator...
 
J

Jukka K. Korpela

Neredbojias said:
If you specify a color without a background-color or vice versa on
any element, the validator will give a warning.

The CSS checker, misleadingly named "CSS Validator", indeed issues a
useful warning.
In some cases it's ridiculous (-not all,)

No it isn't. The ridiculous part is that authors complain about the
useful warning with outbursts that clearly demonstrate why the warning
is useful and almost always points at a design mistake: authors do not
understand the cascade.
but the validator is the validator...

No it isn't.
 
N

Neredbojias

With neither quill nor qualm, Jukka K. Korpela quothed:
The CSS checker, misleadingly named "CSS Validator", indeed issues a
useful warning.


No it isn't. The ridiculous part is that authors complain about the
useful warning with outbursts that clearly demonstrate why the warning
is useful and almost always points at a design mistake: authors do not
understand the cascade.

Suppose I have many lines of white text and decide to span one word to
change its color to yellow. Do I need to state a background? I think
not.
No it isn't.

Well... It purports to be a validator, is from the w3c, and is
internationally recognized, so despite its errors I think it could be
legitimately called a "validator" but I don't necessarily disagree with
the import of your statement.
 
A

Alan J. Flavell

Suppose I have many lines of white text and decide to span one word
to change its color to yellow. Do I need to state a background?

Do you "need" to? - No, you're entitled to ignore a warning, but it's
best to understand the warning before deciding to ignore it. Consider
e.g cascading with a stylesheet which defined the background for span
to be yellow.

Is it *good practice* to do so? - I'd say yes, and so say the folks
at the W3C CSS "validator". But sometimes there's no choice (e.g if
you want the background image of an outer element to "shine through"
an inner element at the same time as specifying text colour for that
inner element).
Well... It purports to be a validator,

The problem here is that in an SGML/XML context, the term "validator"
has a very specialised meaning, which matters (or ought to) to HTML
authors. CSS is neither SGML nor XML, and those who care about the
meaning of words would prefer not to have the water muddied by this
kind of sloppy terminology.
 
N

Neredbojias

With neither quill nor qualm, Alan J. Flavell quothed:
Do you "need" to? - No, you're entitled to ignore a warning, but it's
best to understand the warning before deciding to ignore it.

Agreed, -at least you should understand the css cascading of style
sheets which prompt the warning.
Consider
e.g cascading with a stylesheet which defined the background for span
to be yellow.

Since you surely mean a user stylesheet, suppose my body text color was
yellow? -With a brown body background? If a hypothetical user
_overrides_ page settings, it is his responsibility to ensure that he
does not err in his endeavors. "Cascading" does _not_ mean having to
set a background-color for every color designated. In fact, it means
rather the opposite.
Is it *good practice* to do so? - I'd say yes, and so say the folks
at the W3C CSS "validator".

You're undoubtedly right here, but it reminds me a lot of Microsoft's
old practice of "covering for" third-party mistakes. That does not lead
to markup excellence.
But sometimes there's no choice (e.g if
you want the background image of an outer element to "shine through"
an inner element at the same time as specifying text colour for that
inner element).
Transparent??


The problem here is that in an SGML/XML context, the term "validator"
has a very specialised meaning, which matters (or ought to) to HTML
authors. CSS is neither SGML nor XML, and those who care about the
meaning of words would prefer not to have the water muddied by this
kind of sloppy terminology.

Okay, I dunno, and I'm not that much into it to be persnickety. I do
know the damn thing has errors, so whether a "validator" or a "checker",
it's flawed.
 
J

Jukka K. Korpela

Neredbojias said:
- - at least you should understand the css cascading of style
sheets which prompt the warning.

People who understand the cascade won't ignore the warning. (Well, once
in a blue moon they might - but they do it knowing what they are doing
and not whining about the warning).
Since you surely mean a user stylesheet,

I don't know what Alan had in his mind, but surely there might be a
browser style sheet, too, or another author style sheet (say, after,
ACME has bought all rights to your pages for an indecent sum of money
and made them available in a context where ACME corporate style sheet
is used, too).
suppose my body text color
was yellow? -With a brown body background?

Your body text color and background are, as other properties,
determined in the cascade.
If a hypothetical user
_overrides_ page settings, it is his responsibility to ensure that
he does not err in his endeavors.

Yes, and the author has his part of the game to take care of.

If both set color whenever setting background and vice versa, and do
that well (with sufficient contrast), the serious problem of (say)
yellow on yellow can be avoided. If _you_ set only color for <span>,
then _you_ have a mistake, and it does not help that the user did his
job well.
"Cascading" does _not_ mean
having to set a background-color for every color designated. In
fact, it means rather the opposite.

The opposite? Don't be ridiculous.

In the cascade, every property is handled separately for each element
(after we have conceptually expanded all shortcuts). This might be a
fundamental design flaw in CSS, but it's there. It implies that if you
set the color property for an element without setting the background
properties, the cascade may give the element any background.

Even if you do things right, it is possible to break things, since a
user style sheet could override your color setting and not set
background. But _that_ would be a user's error, which is quite
comparable to the author's mistake we are discussing.
Transparent??

Transparent means that you accept that whatever the cascade happens to
assign as value to the parent element's background property this time
will appear as the background.
I do know the damn thing has errors, so whether a "validator" or a
"checker", it's flawed.

It has its share of errors, but the warning you are complaining about
is not among them.
 
T

Toby Inkster

Jukka said:
Transparent means that you accept that whatever the cascade happens to
assign as value to the parent element's background property this time
will appear as the background.

If you control all of the HTML, then specifying something like:

STRONG {
color: red;
background: transparent;
}

in CSS might make sense, because you may know that you'll only ever use
<strong> within <div id="content"> which has an off-white background.

But if there are multiple markup authors, then "background:transparent"
might be almost as useless as not specifying a background at all.
 
A

Alan J. Flavell

If you control all of the HTML, then specifying something like:

STRONG {
color: red;
background: transparent;
}

in CSS might make sense,

Ah, you say you "control all of the HTML": but who controls "all of"
the CSS?

At the very least, the /user/ has every right to cascade their own
stylesheet with the one provided by the author. And it wouldn't
surprise me if some kinds of service provider were to impose a
stylesheet of their own, in addition to what the author provides.
There's a long history of service-providers injecting
syntactically-invalid fragments of HTML into the web pages of their
customers, after all - who's stopping them from doing much the same
with stylesheets?

And it's not unknown for corporates to insist on their corporate
stylesheet being applied for house consistency. Their management can
decree at any moment a complete change of the house style - so a
one-off exercise of ensuring that the author's styles jive well with
the *current* corporate stylesheet is by no means a complete solution.
But if there are multiple markup authors, then
"background:transparent" might be almost as useless as not
specifying a background at all.

Well, a transparent background is the "initial value"; so the only
difference between specifying it and not specifying it is the question
of what priority it gets in the cascade.

cheers
 
E

Els

Alan said:
Well, a transparent background is the "initial value"; so the only
difference between specifying it and not specifying it is the question
of what priority it gets in the cascade.

That, and validation, or rather, seeing possible errors in the
validator results without having to wade through the 'missing
background-color' warnings.
 
N

Neredbojias

With neither quill nor qualm, Jukka K. Korpela quothed:
People who understand the cascade won't ignore the warning. (Well, once
in a blue moon they might - but they do it knowing what they are doing
and not whining about the warning).


I don't know what Alan had in his mind, but surely there might be a
browser style sheet, too, or another author style sheet (say, after,
ACME has bought all rights to your pages for an indecent sum of money
and made them available in a context where ACME corporate style sheet
is used, too).


Your body text color and background are, as other properties,
determined in the cascade.


Yes, and the author has his part of the game to take care of.

If both set color whenever setting background and vice versa, and do
that well (with sufficient contrast), the serious problem of (say)
yellow on yellow can be avoided. If _you_ set only color for <span>,
then _you_ have a mistake, and it does not help that the user did his
job well.


The opposite? Don't be ridiculous.

In the cascade, every property is handled separately for each element
(after we have conceptually expanded all shortcuts). This might be a
fundamental design flaw in CSS, but it's there. It implies that if you
set the color property for an element without setting the background
properties, the cascade may give the element any background.

Even if you do things right, it is possible to break things, since a
user style sheet could override your color setting and not set
background. But _that_ would be a user's error, which is quite
comparable to the author's mistake we are discussing.


Transparent means that you accept that whatever the cascade happens to
assign as value to the parent element's background property this time
will appear as the background.


It has its share of errors, but the warning you are complaining about
is not among them.

Yep, you're right. I started replying in a much different manner than
this, but as I was describing a hypothetical scenario, I saw it.

Suppose I have white text/brown background on the body. I span a word,
coloring it yellow, sans background. The user comes along and styles
the body color brown and the body background yellow (including both
attributes correctly.) My spanned word "disappears" and I am at fault.

I really thought that _always_ setting both color and bg wasn't
necessary. What can I say? Would you accept a humble "oops"? Please
don't banish me to Finland 'cause I hate cold weather...
 
H

Harlan Messinger

Alan said:
The problem here is that in an SGML/XML context, the term "validator"
has a very specialised meaning, which matters (or ought to) to HTML
authors. CSS is neither SGML nor XML, and those who care about the
meaning of words would prefer not to have the water muddied by this
kind of sloppy terminology.

I don't quite get that. Neither the term nor the concept "validator" was
invented or is owned by the people who wrote the SGML and XML standards.
It's been defined by them for use in those contexts, but that has no
bearing on legitimate plain-English uses of the word outside of those
contexts. As you say, CSS is neither SGML nor XML, so one need make no
reference to the SGML or XML standards to use the term "validator" in
the context of CSS.
 
H

Harlan Messinger

Toby said:
If you control all of the HTML, then specifying something like:

STRONG {
color: red;
background: transparent;
}

in CSS might make sense, because you may know that you'll only ever use
<strong> within <div id="content"> which has an off-white background.

But the user may have a stylesheet with

STRONG { background-color: red ! important; }

though I doubt it. However, in your scenario, you could use the selector

div#content STRONG

instead. The user's stylesheet is highly unlikely to have anything
applicable that's of higher specificity than that.
 
J

Jukka K. Korpela

Harlan Messinger said:
But the user may have a stylesheet with

STRONG { background-color: red ! important; }

though I doubt it.

Well, it's a poorly written style sheet since it does not specify
color. We cannot protect against such style sheets. We can and should
protect against clashes with technically well-designed user style
sheets, such as

STRONG { background-color: red ! important; color: white ! important; }

(which would not result in a problem in this case) _or_ the same
without the !important specifiers.
However, in your scenario, you could use the
selector

div#content STRONG

instead. The user's stylesheet is highly unlikely to have anything
applicable that's of higher specificity than that.

Specificity isn't all. A user style sheet can trump all rules in an
author style sheet, even using the least specific selector *:

* { color: white !important; background: black !important; }

In this case, problems would arise if the user style sheet had

div { color: white !important; background: red !important; }

But things really get _more difficult_ when people try to avoid
declaring colors and backgrounds together. I can understand some
reasons to such reluctance, but there's really no other way to write
robust style sheets.
 
J

Jukka K. Korpela

Els said:
That, and validation, or rather, seeing possible errors in the
validator results without having to wade through the 'missing
background-color' warnings.

You can switch off the warnings if you like.

Of course, there's always the option of actually fixing what's broken,
but why would anyone do so when the wrong may appears to be working
this sunny afternoon?
 
E

Els

Jukka said:
You can switch off the warnings if you like.

Too paranoid for that - you never know if there would be any warning
you want to know about ;-)
Of course, there's always the option of actually fixing what's broken,
but why would anyone do so when the wrong may appears to be working
this sunny afternoon?

Because we are glued to the computer anyway, so it doesn't really
matter if it's sunny or not? Besides, although it was sunny earlier,
it looks all grey outside now.

(not sure what it is you're referring to that's broken)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top