Forum Moderators: not2easy
Example: (using Jigsaw at w3)
Warnings
Line : 48 (Level : 1) You have no background-color with your color : A:link
Line : 48 (Level : 1) Same colors for color and background-color in two contexts a:hover and A:link
Line : 49 (Level : 1) Same colors for color and background-color in two contexts a:hover and A:visited
Line : 49 (Level : 1) You have no background-color with your color : A:visited
Line : 50 (Level : 1) You have no background-color with your color : A:active
Line : 54 (Level : 1) You have no background-color with your color : A:link.navlink
Line : 55 (Level : 1) You have no background-color with your color : A:visited.navlink
Line : 56 (Level : 1) You have no background-color with your color : A:active.navlink
Line : 372 (Level : 1) You have no background-color with your color : .smallspec
Line : 378 (Level : 1) You have no background-color with your color : .itemprice
Now, I know I could just go into the CSS and add all the necessary background colors (which is the most common warning I get), but the problem is (especially with tags associated with links), I DON'T WANT TO SPECIFY A BACKGROUND COLOR...
My reasons:
I choose a small set of colors for a website design and want the links to all appear the same on ANY background color.
Additionaly, I use a navigation method where the HOVER reverses the colors, (ie- as in "A:link.navlink" above), I may use #000000 color on #FFFFFF background, then "HOVER" is #FFFFFF color on #000000 background...
I put the navigation links on top of a container DIV that has a background that is neutral to the foreground/background colors, (ie, #F0F0F0). The problem stems from the fact that the underlying BODY tag has #FFFFFF set (usually).
If I had to declare background for every instance where a link appears (ie- link may appear on DIV that has #FFFFFFF, #F0F0F0 or #FFF0F0 background), then I might as well go back to using <FONT color="#?"> tags --- it would bloat my HTML with redundant inline CSS or class declarations.
As to the "in two contexts" warnings, (for <A> LINK, HOVER, ACTIVE and VISTED values), I like the look of a page where the links DON'T change colors... it was effective in the old HTML 1 / LYNX type browsing, but with CSS and modern navigation methods you don't want a page to get junked up with grey-out visited links and there is virtually no lag time between a click and the called page appearing, so "ACTIVE" is pretty much outdated unless you still have a 1200bps modem).
So, the question: Do SE's weigh CSS bg/fg color warnings in the mix?
I'm sure if you added:
<table bgcolor="#FFFFFF"><tr><td>
<font color="#FFFFFF">
This is a keyword that is a keyword we like keywords key-word key word my keyword your keyword big keyword small keyword..(etc)..
</font>
</td></tr></table>
You would be penalized on (2) counts, once for keyword spamming and additional demerits for same color foreground / background for the text.
I beleive the early algos used it as a gotcha to filter SE spam sites.
NOTE: I used a pure HTML example because I am pretty sure the algos catch that -- but I don't know how much they draw on CSS.
I am 100% "white hat"... I am not trying to hide anything with my color declarations -- I just want to keep the CSS simple.
It's because of accessibility. Sometimes a user will have their own customised stylesheet - for instance, dark blue background with white text (as it's easier to read)
Imagine if you set only a color on your page (#000 is a good example), and not a background colour.
This user will get dark blue background, black text (as your stylesheet is set in their browser to overwrite theirs)
That's perfectly unreadable.
It's not to do with SEO - SEO centres on the content itself, how muddled everything is just to find the content (e.g. tabled layouts), what keywords appear over and over within the content, how many sites link to your site, etc.
a warning is not an error
You do not need to 'get rid of them', you just need to make sure you've checked. What the validator can't do is build your page and check automatically that (for example) your white text in a transparent heading is contained within a div with a blue background. So it warns you to check manually.
I'd like to run a validation and get no errors and no warnings.
The accessability issue makes sense, but I will need to really think if my CSS meets those needs.
If all my "background" properties were #FFFFFF and I didn't use anything but
BODY { background: #FFFFFF; }
They should/would cascade and inherit the background... my problem will be the few times I want to put a class of code on a grey, (example #F0F0F0) background...
Should I define twenty CSS properties (or more) for background for everything or not -- that is the question. The easy answers seem to be;
1. leave 'em out and get warned
2. put 'em in and complicate my CSS for "exceptions"
Setek is exactly right. it's because impaired users may have their browser settings fixed, which CSS usually overrides anyway.
I had this problem with a page of mine, spent hours fixing it and adding weight to the CSS, and it didn't change my search ranking anyway.
In my opinion, unless you need to advertise the fact that your CSS is valid, for example a Web Design outfit, don't worry about it.
Also, I agree with another point in this thread, CSS colours and background colours should inherit automatically from the containing DIV. Maybe something we should ask the W3C.
Chris.
It's because of accessibility. Sometimes a user will have their own customised stylesheet - for instance, dark blue background with white text (as it's easier to read)
Test this for yourselves to see the result of not having specified background colors. While you are welcome to ignore the warnings, they are there to tell you that you have problems in certain situations, in this case, major accessibility problems.
The CSS validator changed about 6-8 months ago. It did not throw up warnings for the things it does now. Here we all are designing using CSS thinking that our stylesheets are flawless and then one day we do a validation only to find 50 warnings in one sheet, another 20 here, etc.
I know how you feel. I hate seeing those warnings. Unfortunately if I were to go back to every stylesheet I've set up, there would need to be some changes on the sites also to accomodate for background colors. It opens a big can of worms. I've been forcing background colors now ever since the validator changed. It's been tough trying to clean up warnings with existing designs.
P.S. background:none and background:transparent will still get flagged as a warning since you are not explicitly setting a background color.
Not with colour, not with image, not with position, nothing.
Just because it would make a few people's lives easier in not having to manually do it themselves, doesn't mean it's a good idea -overall-.
If you want -all- your background colours to be #fff, with that one exception of a gray, why don't you do this?
* { background: #fff; }If you don't see the need to manually set a background colour with every colour, and vice versa, because you don't think your website requires that sort of accessibility, then why do you need to have a stylesheet with no errors or warnings?
Begging your pardon, but that just sounds like elitism, or doing things for the sake of doing them, without real purpose or reason.
unless you need to advertise the fact that your CSS is valid, for example a Web Design outfit, don't worry about it
No, that's my above point. Warnings are not errors. This doesn't invalidate your CSS.
CSS colours and background colours should inherit automatically from the containing DIV
colours do; background colours don't. Background-color defaults to 'transparent' and doesn't inherit. In normal flow then this acts like it does, but try absolutely positioning an element and you'll see that it doesn't inheirt a background colour.
* { background: #fff; }
actually changed it to;
* {
background: #fff;
color: #000;
}
(Because even your suggested CSS threw up a warning for not declaring a color with the background)... After my fix it still throws up the warnings for CSS declarations that do not specify both color and background.
# Line : 53 (Level : 1) You have no background-color with your color : A:link.navlink
# Line : 54 (Level : 1) You have no background-color with your color : A:visited.navlink
# Line : 56 (Level : 1) You have no background-color with your color : A:active.navlink
# Line : 58 (Level : 1) Same colors for color and background-color in two contexts a:hover and A:link
# Line : 58 (Level : 1) You have no background-color with your color : A:link
# Line : 59 (Level : 1) You have no background-color with your color : A:visited
etc...
It really should inherit and cascade -- isn't that the promise of CSS?
I've been forcing background colors now ever since the validator changed. It's been tough trying to clean up warnings with existing designs.
However, if you view the amount of warnings, isn't css supposed to reduce code bloat? Now with having to add the background colors to all items that you would not have done so to before, this increases the page load.
Which goes back to my initial question, CSS is supposed to reduce code bloat, not increase it.
Would be interested in opinions on this one.
"...why do you need to have a stylesheet with no errors or warnings?""...that just sounds like elitism, or doing things for the sake of doing them, without real purpose or reason".
- Setek
#1. I'd like to pass through the validator with no warnings for the same reason I want my code to validate -- for the sake of doing it right and appeasing the web gods. Please proceed to #2.
#2. please go to #1
:)
Your code is still valid even if there are warnings.
As I said, "I'd like to pass through the validator with no warnings for the same reason I want my code to validate". (which ARE two different things)...
I always make sure my CSS validates, I'd just like to not pull warnings, (I'm a web designer / developer and don't want my customers to ask "What's this" if they check the validator).
Thanks.
Then when your client checks the page (though not sure how many really do this) your page works.
Though I do need to caution you, I have done work on pages that have went onto others that had work to do such as programing, and what they have done has somehow messed with my css. Not sure of the whys of this though.
I've seen my css get indexed by yahoo...I couldn't believe it.
It really should inherit and cascade -- isn't that the promise of CSS?
No.
It would be a disaster if everything inherited--imagine if e.g. borders were inherited...
-b
If you are bothered about this sort of thing, as I imagine most on this CSS forum are, go the extra mile.
Which, doesn't really make any sense, because neither Yahoo nor Google validate as valid html... Who does? MSN. That's right -- Remember that next time anyone says that Microsoft doesn't adhere to 'standards'. ;-)
I think for the most part that is the point being missed here, validation is supposed to help you know that your page needs additional work, or that it has passed the validation.
If warnings are new and are needed for accessability, then abide by them. Learn from them. If you were someone who depended on a site being accessable, you would be thankful that someone took the extra time to get it right. ;)
'In early SEO days '
as well as today
.
If your css doesn't validate, then your pages aren't going to function properly.
I agree; I should have been more specific and said validatation with warnings is 'okay' -- I agree that 'errors' need to be corrected. I work inside a government agency where there is a growing initiative to make web pages accesible, not only in terms of xtml and css validation, but bobby validation as well.
but bobby validation as well
-DRshield
That's it, I'm firing up the 8086/mono-herc machine.
I choose a small set of colors for a website design and want the links to all appear the same on ANY background color. "
I honestly don't understand this. How could could it look "the same" if it turned out the background color was the same as the link color?! Wouldn't it be invisible?
"Now, I know I could just go into the CSS and add all the necessary background colors..."
Using the "cascading" part of CSS, you only need to enter a background color once to avoid this message (like by giving the "body" section and id). Everywhere else that you specify one, the original will be over-ridden. Where you don't specify one, you shouldn't get the error.
-KB
Validation is a tool for YOU (and maybe your clients if they're looking).
Keep things in perspective.
...what I am saying by "the same" is that I prefer to have the a:active, a:visited, a:hover set to the same forground and background colors as the a:link tag.
It was common in pre-CSS HTML design to set the colors so that a link was one color, it would change to another color when it was "active" and if you returned to the same page, a link you've "visited" would be another color...
(examples in HTML then CSS equiv)
HTML:
<BODY BGCOLOR="#000040" TEXT="#FFFFFF" LINK="#00FF00" ALINK="#FF0000" VLINK="#FF00FF">
CSS:
BODY { color:#FFFFFF; background:#000040; }
a:link {color:#00FF00; background:#000040;}
a:visited: {color:#FF00FF; background:#000040;}
a:hover { color:#0000FF; background:#000040;}*
a:active { color:#FF0000; background:#000040;}
Note: I've defined the "background" (5) times even though the (4) "a:?" selectors use the same background as the BODY style... which is the focus of this thread --- without defining it over and over, it throws up a warning on the validator that no background color was provided. (Also we are discussing if the lack of CSS color definitions have any negative impact as far as SE's are concerned).
In addition, I used light colored text and links on a dark background in my examples to demonstrate what people are saying is the reason for this --- without the redundant definitions, a browser may default to its (dark on light or other) style and render the text and links impossible to read.
With no CSS styling or HTML <FONT COLOR="#.."> markup, most older browsers defaulted to blue underlined links that turn red when they were clicked, (the called page's URL was "active"), and then were rendered grey if the link appeared again after being "visited".
*NOTE: you could only define "hover" in pre-CSS HTML if you defined it using javascript for mouse-overs).
