homepage Welcome to WebmasterWorld Guest from 174.129.130.202
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderator: open

CSS Forum

This 44 message thread spans 2 pages: 44 ( [1] 2 > >     
Valid CSS with "Warnings" --- SEO Drawback?
Do SE's penalize when CSS validates with color warnings?
lexipixel




msg:3061965
 8:55 am on Aug 27, 2006 (gmt 0)

Lately I have been trying to write CSS that validates with no "warnings", but at times there are design features I need (or "want") to use that throw up a warning on pages that otherwise validate.

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?

 

RonPK




msg:3061969
 8:57 am on Aug 27, 2006 (gmt 0)

Very unlikely. Why should they care?

lexipixel




msg:3061978
 9:10 am on Aug 27, 2006 (gmt 0)

In early SEO days (before the SE's had to use counter measures to fight keyword spam) people would add a couple hundred words at the bottom of a page in same color foreground and background colors --- the text was "invisible" to the human eye, but the page was loaded with keywords.

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.

RonPK




msg:3061980
 9:19 am on Aug 27, 2006 (gmt 0)

Well, I seriously doubt that SEs care about valid CSS. I can imagine them worrying about using the same colours for foreground and background, and about visibility:hidden and display:none. But on the other hand, I've personally never seen a search engine requesting a CSS file.

Setek




msg:3063936
 4:34 am on Aug 29, 2006 (gmt 0)

The reason why the CSS validator pulls those up with warnings is not for that reason.

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.

SilverLining




msg:3064239
 12:14 pm on Aug 29, 2006 (gmt 0)

Lexipixel, I've had that same issue before. You can specify background: none or background: transparent on the element the CSS validator is complaining about, but I agree that it's not really worth having so much unnecessary CSS code just to Validate 100% . Would be nice to find a solution for this as you don't really want to specify the bgcolor on every parent div. Anyone else with suggestions?

Robin_reala




msg:3064250
 12:28 pm on Aug 29, 2006 (gmt 0)

The 'transparent' get around is ridiculous as it completely ignores the original reason they're there. The imporant point is that:

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.

lexipixel




msg:3066400
 8:18 pm on Aug 30, 2006 (gmt 0)

Thanks for the feedback and suggestions. Still not sure what I'll do (if anything).

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"

4css




msg:3066458
 9:02 pm on Aug 30, 2006 (gmt 0)

I agree with Robin on this, a warning is not an error and doesn't cause you to fail validation. You will see that you have passed validation with warning.

ChrisBolton




msg:3066675
 12:23 am on Aug 31, 2006 (gmt 0)

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.

pageoneresults




msg:3066727
 1:14 am on Aug 31, 2006 (gmt 0)

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.

Setek




msg:3066780
 2:21 am on Aug 31, 2006 (gmt 0)

I don't agree with the sentiment that background properties should inherit.

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.

Robin_reala




msg:3066947
 6:45 am on Aug 31, 2006 (gmt 0)

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.

lexipixel




msg:3067196
 11:26 am on Aug 31, 2006 (gmt 0)

SEtek - I tried your idea

* { 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?

4css




msg:3068171
 10:51 pm on Aug 31, 2006 (gmt 0)

I've been forcing background colors now ever since the validator changed. It's been tough trying to clean up warnings with existing designs.

Ok, I do agree with future ones fixing the warnings.

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.

lexipixel




msg:3068222
 12:00 am on Sep 1, 2006 (gmt 0)


"...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

:)

Robin_reala




msg:3068510
 6:46 am on Sep 1, 2006 (gmt 0)

Lexi: you're still missing my point. Doing it right is manually verifying that the warnings are nothing to worry about, then leaving it at that. The warnings are there because there could be a problem that the validator can't check.

Your code is still valid even if there are warnings.

lexipixel




msg:3069038
 5:46 pm on Sep 1, 2006 (gmt 0)

Robin, I understand the point.

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.

4css




msg:3069251
 8:16 pm on Sep 1, 2006 (gmt 0)

lexipixel
If you wish to pass through with no warnings, then heed the ones that arise and remember them. IF you should get them it is really easy to go back to your css style sheet and fix those warnings.

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.

texasville




msg:3069479
 12:08 am on Sep 2, 2006 (gmt 0)

>>>>But on the other hand, I've personally never seen a search engine requesting a CSS file. <<<<

I've seen my css get indexed by yahoo...I couldn't believe it.

bedlam




msg:3069523
 1:45 am on Sep 2, 2006 (gmt 0)

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

esllou




msg:3069533
 2:06 am on Sep 2, 2006 (gmt 0)

I just went through this with a new site. Determined to be valid html strict and css - and have the buttons to prove it. It took me 2 extra minutes to get rid of the warnings about colors and I now have a shiny CSS Validated button in my footer.

If you are bothered about this sort of thing, as I imagine most on this CSS forum are, go the extra mile.

drshields




msg:3069548
 2:56 am on Sep 2, 2006 (gmt 0)

From my experience, I have found that xhtml validation weights a lot more than CSS validation -- if CSS even matters at all.

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'. ;-)

4css




msg:3069557
 3:09 am on Sep 2, 2006 (gmt 0)

drshields
If your css doesn't validate, then your pages aren't going to function properly.

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. ;)

blend27




msg:3069573
 3:30 am on Sep 2, 2006 (gmt 0)

lexipixel

'In early SEO days '

as well as today

.

drshields




msg:3069667
 6:21 am on Sep 2, 2006 (gmt 0)

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.

lexipixel




msg:3069767
 9:36 am on Sep 2, 2006 (gmt 0)

but bobby validation as well
-DRshield

That's it, I'm firing up the 8086/mono-herc machine.

patiodragon




msg:3069893
 2:39 pm on Sep 2, 2006 (gmt 0)

"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. "

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

jessejump




msg:3070109
 8:00 pm on Sep 2, 2006 (gmt 0)

I think most seasoned designers are fine with getting warnings only and also with not validating their HTML completely if they "know" that the page will be OK.

Validation is a tool for YOU (and maybe your clients if they're looking).
Keep things in perspective.

lexipixel




msg:3070199
 10:46 pm on Sep 2, 2006 (gmt 0)

patiodragon,

...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).

This 44 message thread spans 2 pages: 44 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved