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?
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.
This--as has already been pointed out in this thread--is patently untrue. Further reading:
@lexipixel
I've defined the "background" (5) times even though the (4) "a:?" selectors use the same background as the BODY style
Well, this should tell you three things:
You probably already know that the order of link pseudo-classes in CSS is important [w3.org]. This is because they're all of the same specificity as one another. The spec doesn't seem to spell this out explicitly, but it does say, when describing how user-agents should calculate CSS properties of elements in the cascade that user-agents should
3. Sort rules with the same importance and origin by specificity of selector: more specific selectors will override more general ones. Pseudo-elements and pseudo-classes are counted as normal elements and classes, respectively. (my italics)source [w3.org]
In other words, a:hover and a:visited are both weighted (as far as specificity is concerned) as 'a'. This means that properties of e.g. a:hover override those of a:visited only if they come later in the stylesheet (assuming of course that the selector [w3.org] of one is not in some other way more specific than the other).
This means, in turn, that the validator should not issue warnings for the case you've laid out above. The difference between pseudo classes is, in terms again of specificity, identical to the following:
a { background-color:#f00; }
a { color:#090; }
It simply would not make sense for the validator to issue warnings about the second line since an identical selector has already been used to define the background-color. In my opinion, the validator should be sophisticated enough to determine that when any equally specific element declaration has a background-color, then so do subsequent pseudo-classes of the same element. It should either a) issue an error if there is a conflict, or b) issue no warning.
Besides, if this is just about linking your CSS to the validator as a sort of 'vanity validation,' why not link to the advanced interface that allows you to turn warnings off [jigsaw.w3.org]?
-b
[lists.w3.org...]
And the reason the validator gives the warning is set out by Bjoern Hoehrmann (a former member of the W3C's QA group), with suggestions as to possible resolutions to your problem.
[lists.w3.org...]
If you simply want to produce a page that looks identical to what you already have but with no validator warnings, the simplest way to achieve this is to make sure that whenever you specify a font color you supply either a transparent or inherited background. eg:
body{ color:#000; background:#fff;}
p{ color:#666; bacground:transparent;}
a{ color:#f00; background:transparent;}
Note that it is not necessary to specify a background color for *every* element in the cascade, simply elements where a color has been specified. This doesn't necessarity fix the original accessibility problem. But it should at least ensure that if a user stylesheet interacts with your stylesheet, both color properties will be overridden at the same specicifity.
There is an explanation of the differences between the values 'transparent' and 'inherit' here:
[lists.w3.org...]
As to your original question as to whether search engines are clever enough to calculate the computed style of any element on the page and work out if it is, say, white text on a white background, there are tools available for web developers that do just that, so it's not impossible, though it might be computationally expensive.
These issues came up on the w3c validator list. The reasons why not setting both color and background-color properties is considered a problem is set out by Ian Hickson (an author of CSS)
[lists.w3.org...]And the reason the validator gives the warning is set out by Bjoern Hoehrmann (a former member of the W3C's QA group), with suggestions as to possible resolutions to your problem.
[lists.w3.org...]
The reasons they give have been pretty well thrashed out here already, though neither of the messages above is particularly relevant to the specific question of links with pseudo-classes.
In the case of different pseudo-classes of the same element, there is no parent-child-inherit relationship, and there is no difference in specificity: 'a:hover' is as specific as 'a,' and the validator is pretty simple-minded when it comes to these cases.
However, the case is also slightly more complex than what I posted in my previous post. In certain cases, I would still say that the validator is in error to output warnings, and in many cases it would be nice to have a more nuanced output. IMO For example, the following CSS should not generate a warning from the validator in the following cases:
a:link { background:#090;color:#000; }
a:hover { color:#900; }a { background:#090;color:#000; }
a:hover { color:#900; }Again, the issue is that the element presumed to have no background-color--a:hover--has an explicitly set background-color. In fact, every link in a document styled with one of the CSS fragments above has a background-color.
On the other hand, the following CSS should not as I said earlier generate an error--the CSS is valid--but it's quite correct to ouptut a warning:
a { background:#090;color:#000; }
a:hover { color:#090; }This case is also relevantly different from other cases where the validator ouputs warnings since the same element (albeit in different stages of user-interaction) has explicitly set identical background and text colours. This is the sort of circumstance where it would be nice if the warnings were a bit more emphatic--this CSS is guaranteed eventually to cause problems; it's not a hypothetical case of "there is no explicit background, so what if a user stylesheet sets the background-color to the same color as the text..."
-b
bedlam: I didn't realize my post was such a worm can opener. Maybe we need to start a new thread on speciificity regarding the a: psuedo-classes...
I think I have my (2) answers;
1. Warnings may be ignored but accessability issues may arise, (as a workaround, to at least set background-color: transparent; if I specify a font color:).
2. SE's don't check CSS (except MS which may).
If you simply want to produce a page that looks identical to what you already have but with no validator warnings, the simplest way to achieve this is to make sure that whenever you specify a font color you supply either a transparent or inherited background. eg:body{ color:#000; background:#fff;}
p{ color:#666; bacground:transparent;}
a{ color:#f00; background:transparent;}-broxtt
oops... I assumed you were correct, you weren't... the validator threw the warnings with the background:transparent;.
Here's the CSS:
a:link { color: #006699; background: transparent;}
a:visited { color: #006699; background: transparent;}
a:hover { color:#FFFFFF; background-color: #006699; text-decoration:underline;}
a:active { color: #006699; background: transparent;}
a:link.navlink { line-height: 1em; font-size: 11px; font-weight: bold; color: #0000C0; background: transparent; text-decoration: none; }
a:visited.navlink { line-height: 1em; font-size: 11px; font-weight: bold; color: #0000C0; background: transparent; text-decoration: none; }
a:hover.navlink { line-height: 1em; font-size: 11px; font-weight: bold; color: #0000C0; background-color: #FFFFFF; text-decoration: none;}
a:active.navlink { line-height: 1em; font-size: 11px; font-weight: bold; color: #0000C0; background: transparent; text-decoration: none; }
Here's the WARNINGS!
# Line : 46 (Level : 1) You have no background-color with your color : a:link
# Line : 47 (Level : 1) You have no background-color with your color : a:visited
# Line : 49 (Level : 1) You have no background-color with your color : a:active
# 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
(FWIW, I tried the same CSS using "background" and "background-color", but throw the same warnings at:
[jigsaw.w3.org...]
a:link { color: #006699; background: transparent;}
a:visited { color: #006699; background: transparent;}
a:hover { color:#FFFFFF; background-color: #006699; text-decoration:underline;}
a:active { color: #006699; background: transparent;}a:link.navlink { line-height: 1em; font-size: 11px; font-weight: bold; color: #0000C0; background: transparent; text-decoration: none; }
a:visited.navlink { line-height: 1em; font-size: 11px; font-weight: bold; color: #0000C0; background: transparent; text-decoration: none; }
a:hover.navlink { line-height: 1em; font-size: 11px; font-weight: bold; color: #0000C0; background-color: #FFFFFF; text-decoration: none;}
a:active.navlink { line-height: 1em; font-size: 11px; font-weight: bold; color: #0000C0; background: transparent; text-decoration: none; }
Lexipixel, the CSS above is a) very bloated, and b) contains errors (you have mixed up the order of class and pseudo-class on your links in the second block of code*). Try this instead (and recall that all pseudo-classes of a given element have equal degrees of specificity; this means you don't need to re-define each property in each new pseudo-class):
a:link { color:#069; background:transparent; }
a:hover { color:#fff; background:#069; text-decoration:underline; }a.navlink:link { line-height:1em; font-size:11px; font-weight:bold; color:#0000c0; background:transparent; text-decoration:none; }
a.navlink:hover { background-color:#fff; }
This should reduce the number of link-related warnings by half on its own--there are now only half as many lines...
-b
*I have no idea why the validator thinks this is valid CSS--check out e.g. the section of the CSS Spec's page on selectors that deals with pseudo-classes [w3.org] to see examples containing the correct syntax.
The 'transparent' get around is ridiculous as it completely ignores the original reason they're there.
I still maintain my (and many others') standpoint that a warning is not an error, the warning generated is due to accessibility issues (i.e. user-defined stylesheet clashing as per specified colours w/o specified background colours.)
'Transparent' is just as useless as not having anything there.
And while I believe that going to this trouble of "tying all loose ends" for a good reason, such -as- accessibility, is a warranted effort, I -don't- believe doing such because of unsubstantiated elitism is one of those good reasons.
So I'm out of this thread, good luck with whatever you decide.
I appreciate the comments but I think we've strayed off topic.
regarding the CSS example I posted; I know it's bloated. I've found that some UA's default to their own style of handling links if I don't specify each psuedo-class, (link, visited, hover, active).
Maybe we can start the new topic with, "What order is correct order of a:link psedo classes?" (I have been using L,V,H,A order). I don't see any other order given in the CSS2 specs.
Bedlam-- lets wrap it up here and (possibly) start a new topic on specificity of the a:link psuedo classes.
I appreciate the comments but I think we've strayed off topic.
Not really; if you want to reduce the number of warnings you're getting from the validator, the absolute best step you could take would be to group properties. Besides that, I don't see how it could have been off-topic to point out the actual errors in your code sample.
regarding the CSS example I posted; I know it's bloated. I've found that some UA's default to their own style of handling links if I don't specify each psuedo-class, (link, visited, hover, active).
I'd be interested in hearing more about this-- since I have not experienced this with any reasonably modern browser. Are you talking about some more exotic UAs (phone/handheld browsers for example)?
-b
Valid CSS with "Warnings" --- SEO Drawback?
Do SE's penalize when CSS validates with color warnings?
It seems pretty big leap for you to assume I suggest starting a new thread because you pointed out an error in my CSS, (which doesn't throw an error or a warning from the validator and is syntactical in nature), and which I commented that I appreciate you pointing out.
re: UA's handling links differently-
Your "lean example" only defined a:link and a:hover... On "my copy" of MS-IE 6 on XP-Pro the "visited" color of links defaults to the browser style, (a purplish color). In FireFox 1.5 (on XP-Pro) it doesn't change at all.
I'm not about to code for the top 10 browser/version/OS combos separately, so I use the "better safe than sorry" method of defining every element I feel is important to my design, (e.g.- I use margin-bottom:0px; on <FORM> tags to overcome how different browsers handle that one).
If you have a cross-browser example of lean CSS that accomplishes what I described, feel free to post it.
[edited by: lexipixel at 10:34 am (utc) on Sep. 4, 2006]
a:link { color: #069; background: inherit;}
a:visited { color: #069; background: inherit;}
etc
Note that I'm not saying that this is the right or best thing to do. That the warnings are there to be suggestions for accessiblity best practice and should just be ignored or excluded seems to be the feeling of the W3C validator team, which is why I included the link to Bjoern Hoehrmann's post.
Your "lean example" only defined a:link and a:hover... On "my copy" of MS-IE 6 on XP-Pro the "visited" color of links defaults to the browser style, (a purplish color). In FireFox 1.5 (on XP-Pro) it doesn't change at all.
Yes, you're partially correct. You're right that the default ('a' or 'a:link'), and :visited states should be defined. However this doesn't change the sample I posted much at all--use grouping as I suggested earlier:
a:link,
a:visited { color:#069; background:transparent; }
a:hover,
a:active { color:#fff; background:#069; text-decoration:underline; }a.navlink:link,
a.navlink:visited { line-height:1em; font-size:11px; font-weight:bold; color:#0000c0; background:transparent; text-decoration:none; }
a.navlink:hover,
a.navlink:active { background-color:#fff; }
The :active pseudoclass in the sample above can be omitted if you'd prefer (as in your original code sample) to have the active state styled identically to the default state (again, it's about specificity...)
-b
I'm not going to go there as it is a different topic
First off, I can not see the warnings as being a drawback to SEO, as I've said before ~ before you even get into specificity there are numerous ways you can use the cascade legitimately to keep the CSS lean, yet the code will still produce "validator warnings" (background images etc..)
Now I presume the validator is producing these kind of warnings because of the old days where it might have been as simple as "white on white" to hide text, but there is NO WAY in this whole world that an algo can account for every single LEGITIMATE use of the cascade and it's subsequent CSS
it's very much like the accessibility validator, the accessibility validator can only produce suggestions in line with the most common errors (remeber CSS is just a suggestion too!), i.e. it can produce a warning here and there but it cannot account for good code!
It will come down to code bloat again unfortunately, you can stick the extra lines (adding a background where they tell you to) in so you get the "cool" error free report or you can know that your code is perfectly fine and will pass a hand inspection and this means you use your CSS wisely. or you can add to it and subsequently may need to go on to defend why, and perhaps perpetuate the SEO myth?
Suzy
