CSS Reboot validation errors dissected
In my post CSS Reboot participants far from standards-based I referred to CSS Reboot as Web Standards Validation Indicator, Sean Fraser’s analysis of the CSS Reboot Spring 2006 participants. Well, Sean has been quite busy since then and has produced an entire article series analysing and discussing the errors found:
- CSS Reboot as Web Standards Validation Indicator
- The Most Common HTML Markup Errors
- The Most Common CSS Markup Errors
- CSS Vendor-Specific Extensions fail
- CSS Validator-Induced Errors
- CSS Spring 2006 Reboot Errors Afterword
Plenty of most interesting reading that will keep you occupied for several cups of coffee (i.e. quite a while). It’s amazing to see the kinds of errors people leave in their markup and CSS. A simple run through the HTML and CSS validators would have caught most of them. So why do people not use the validators? I just don’t get it. What are they gaining by using invalid code?
Nothing.
- Previous post: Prioritizing Web Usability (Book review)
- Next post: Let your users scroll
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
Heres a shot in the dark - they don't really understand HTML or CSS? Maybe they let a wysiwyg do most of the work? I think many think of CSS Reboot as a design contest, and so they will create the design, throw it together with CSS, and then see how it fares. They don't think first and foremost about the structure and semantics.
Just a guess though.
Keeping pages valid is a big pain in the ass. I feel it's not worth the trouble for my personal site.
Validating for me would mean adding alt="" tags to all the images on my site. I'm not going to waste my time going back and adding them to blog entries I wrote three years ago (though I add them to new entries).
Second, HTML validation is a closed, old standards. There are plenty of useless things in it that just make like harder for designers. For instance, why doesn't it support Safari-style input boxes (that btw degrade just fine in other browsers?) - sure there's a hack, but why bother?
And in CSS - why isn't the opacity property supported? It's valid CSS3, even if most browsers don't support it. And why do I have to add background color AND a color for every element where only one is defined? I have to add background-color:inherit - it's inherited by default, for god's sake...why add extra complexity to the code?
I have been coding with CSS for a long time, and HTML likewise. There are no major mistakes in my code. But why should I hack out parts of my site that the validators don't like?
Add to that, every time I add something to the site, it's a 80% chance it won't validate properly.
The CSS validator reports color without background (and vice versa) as warnings, not errors. The stylesheet validates; the validator trying to be "helpful" by pointing out a potential cause of any unexpected colour combinations you might be getting on your page. :)
They are safely ignored most of the time since they are not validation errors.
As for failing HTML validation 80% of the time, you'll get better with experience.
For most personal websites I personally don't think 100% compliance is necessary. It makes sense for the sophisticated error handling already present in text/html browsers to sort out the simple mistakes commonly made by people who aren't markup specialists. The web is supposed to be the place where anyone can publish to a global audience, after all.
However, I think valid code is a minimum level of proficiency for any professional website developer. It's bad service to give clients sub-standard work. They wouldn't accept it if they understood the problems it causes later down the line.
Neither do they, I think.
Many trust their tools or favorite browser to "get it right" by default. The fact that most tools are less than optimized by default, may be a contributing factor. Also: that browsers' error-recovery save so many sites, is also interpreted by many to mean: "it works, so why bother with validation".
Nothing but saving a minute or two - which of course is often lost many times over on trying to make the design work as intended.
The reality is that most "minor" flaws don't make much of a difference, so they may not lose much either.
Nate: Lack of understanding is likely.
Mackie: Fixing legacy content can be problematic, agreed. That is not the problem discussed here though.
HTML isn't meant to be used for design, so I'm not sure what you mean by it making things harder for designers.
As for your CSS errors and warnings, just use the Advanced interface to configure the CSS validator to use CSS 3 if that's what you are checking. You can also turn off the warnings about color and background-color. They are just warnings.
You are on a roll lately, Roger. Give them Hell!
Unless i'm mistaken the colour vs background colour warnings are about having enough contrast and making sure the website is still usable when images are turned off. Right? I need to go through and sort mine out soon - i've only left them for a while because as Ben and Roger point out - it's a warning not an error.
HTML for structure, CSS for design... Just what i was thinking when reading Mackie's comment!
Ben: Your argument that professional web designers owe their clients valid code, is a little much for me to swallow. Most of my clients want cheap and fast. They have no idea about web standards and could care less. It just doesn't have enough impact on their bottom line. I personally love it when my code validates, just because it satisfies my OCD when it comes to coding. It's a tough sell to a client.
I have to ask, is it okay to use vendor specific extensions? For instance when I want to use opacity. So that IE users can see it too, I may use the following in a CSS rule.
opacity: .9;
filter: progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=90);
I know that most browsers will ignore the filter line and why should I put this in an IE only CSS file just to pass the validator when everything else is valid? Why should I punish the user and make them download an extra CSS file for a few vendor specific rules?
Josh: What happens when a potential client reviews sites you've made and finds that they don't validate? I don't sell validation to clients (unless they know about web standards), I build validated client sites because it affects my bottom line. And, like Ben said, "It's bad service to give clients sub-standard work."
Okay, explain it to me. I understand using semantic html and separating presentation from content. I also understand accessibility considerations. However, what real harm, other than to a designer's ego, is there in not validating 100%? Doesn't it mean simply that there is a little glitch in a page? Isn't it still mostly usable to most people? I know XML is all or nothing, but is this?
I just seem to use my Tidy-plugin for FireFox all the time. The problem is that it doesn't catch everything (but most things) which let's some invalud markup slip through every once in a while (mostly what elements are allowed where under certein dtd's. I always seem to forget I can't have spans around inputs in xhtml strict :().
Why do I not use a validator? Because by writing invalid code I can create more semantic code that is cleaner and more understandable.
Here's a nice snippet of perfectly invalid code that gives me extra functionality and extra semantics:
Now using some nice DOM Scripting I can go back and apply this behaviour to all links that have remote="yes" on them, or some other differentiator and apply a universal action. The update attribute of the link describes the relation of the link to the content it will change.
Sure, I could go through the pain that is writing a custom DTD -- but at what gain? What do I gain by writing "valid" code? Nothing.
Sean: If I had to give back all the money I ever made to any client that even knew what valid code was much less checked it before hired me, I would have to give back, you guessed it: $0
The harsh truth is, we (designers/developers), care about strictly valid code. It's a badge of honor, in most cases. But the vast majority of people pumping money into this thing we call the internet, could care less.
Josh: I agree. Utterly.
Interesting thing, though. I've gotten clients because of web standards and valid code when the other teams couldn't explain why web standards is important.
I would offer that your "harsh truth" should be amended. Most developers/designers I've spoken with in the commercial world could care less about web standards (let alone valid code).
Most CSS template manufacturing companies that I've reviewed offer non-validating code for some or all of their templates. Some CSS Spring 2006 Rebooters used Kubrick design templates that didn't validate. And, it is caused by - Greatly - common, simple errors.
A lot of the entries - regarding CSS difficulties with layouts - on mailing lists and forums could have been solved if the developer had tried validation services first.
Tanny: Since it's quite likely that you already have an IE-specific CSS file imported with conditional comments, why not put IE-specific properties there as well? It's one thing to use vendor specific properties that use 4.1.2.1 Vendor-specific extensions, since those are guaranteed not to be used in CSS. Other properties are safest and cleanest to keep out of the main stylesheet(s).
Steve: The actual harm depends on what the error is.
Kyle: I'd say that's what the class attribute is for. No need for invalid code or custom DTDs. But sure, by using custom attributes the way you describe at least you know why you are making your documents invalid. That is quite different from just being ignorant.
The point is not whether or not your clients care about the validator. You shouldn't have to sell them "standards". If people pay good money to a professional they would assume the job is done professionally. If I pay my garage $1200 to fix something in my car I hope they use equipment, materials and procedures which comply to the highest standards.
Having said that, at some point in the process I will explain clients in broad terms what standards are and how they can benefit. Just because many other agencies don't know or care about them (and therefore the client is better off with an agency which does build with standards in mind). And because a large part of the jobs nowadays are redesigns of existing websites. Websites which have been build 5 or 10 years ago, build with horrible code, nested tables, slow-loading and only working in IE and netscape 4.
And to come back to the original topic. I would assume that if you enter a contest/reboot you try even harder to get each and every detail right.
Just to make sure its known, the warnings you get when supplying a background without a colour, or a colour without a background, are there because different browsers have different default settings, and because of things like user stylesheets which are often used to boost the readability for people with poor sight.
So for example, if you've coloured all list elements white, because their parent element has a black background, and the user stylesheet says all list items must have black text, you'll end up with an unreadable list.
Granted it should also be the responsibility of the user stylesheet to account for that, and that it isn't always possible to set a background colour.
The key questions you've raised Roger:
...and
The only problem with the first of these questions is that you're assuming that failed code validation suggests a Validator-tool wasn't used - when in fact it could've been used, but the code itself had issues that couldn't be (or weren't) resolved for any number of reasons (technically exceeded the skill of the author, laziness, unawareness). Your second question is more closely related to the heart of Web Standards itself: of course, little is gained by not using valid code but for some site designers on the CSS Reboot maybe they were possibly asking themselves 'What can be gained by using valid code?'....and we all know the anwers to that one don't we?! :)
@Kyle
You're missing a trick here. Visit Microformats.
@Fredrik:
If you're on Windows, try using the beta version of Marc Gueury's excellent HTML Validator Firefox extension. It uses the same SGML validator codebase as the online W3C Markup Validation Service, so it should give you the same results.
We use this extension at work for web development on our internal sites and Intranet -- I have to say there's nothing quite so satisfying as seeing that green tick of approval. We're training new web team members and they've caught onto the validation bug as well. Oh my!
Who would've thought squashing bad/invalid markup could be so fun? Now all I wish for is a CSS Validator extension along the same lines...
Oh come on now... Maybe if you have time to futz with an old antique system of error checking you might care. But it's bad enough that we designers have to get what we thought would be a agreat design to show up and display correctly among soooo many different broswers.
And then ta-boot code never works the same. Then you tell me to use a standards checker ? Which in it'self makes bad code... D@m who to trust.... Oh thats right! ME.! You trust your self and your eyes, not the man...
Dude get over it, code checkers don't work
If vision isn't the primary sense for consuming information, then what?
@tripdragon It's amazing how much easier it is to get things to work correctly over multiple browsers using valid XHTML and CSS.
Yeah there will be slight differences between browsers but there is nothing you can really do about it.
It is, afterall, a "CSS Reboot" - not a "Standards Compliant Reboot." What would it matter if everything on the site was div and span elements. They're using CSS, right? ;)
But what do they have to gain? Nothing. Most amateur website designers think if it looks good it is good, because to them, it is. They can't tell what it looks like to the blind (for example), nor do they care.
How else will one learn if they are not allowed to fail? How does one really validate "tag soup?" The whole validation/standards regime seems to be more judgemental than steriotypical Christians. I believe we should be available to answer questions or offer support, but not tell people what to do or how to do it.
@Kyle - That's a great idea that I thought about using. If only I hadn't listened to myself when I said, "but that doesn't validate!"
Nothing.
If beginners are attempting to understand CSS positioning in relation to their knowledge of tables-based designs, I would expect them to use div-and-span layouts. Everyone - as I remember - used div-and-span layouts before "semantics" entered and was accepted.
Validation validates code, "Tag-Soup" or "semantically pristine". Hopefully, beginners will - Later - apply their growing knowledge of web standards by culling their soup tags. Like Everyone else.
I'm curious. How many universities are offering lectures on "semantic web design" in their everyday curricula.
The CSS Reboot site has now been redesigned - 27 validation errors on the homepage...
Speaking of "down the line" ... read Owen Briggs' take on validating.
@ Matthew. Kinda.
The Blog has been fixed and validates for Markup and CSS; the acutal CSS Reboot site does not validate for Markup, one style sheet fails due to a single error and the second style sheet fails for being all underscore hacks.
Oh, well.
Most rebooters are self-taught, they are bound to make mistakes. I think they should be rejected untill all mistakes are corrected, and they have at least have a DOCTYPE, semantic markup and a clean and readable stylesheet.
On comment #29 - I wouldn't let validation errors be the judge of how well crafted the site is.
Ouch, my eyes! ;-)
Johan: Yep, I agree. It's part of designing with CSS.
Dustin: Depends on what the errors are, don't you think? (I haven't checked.)
So Roger: Why dont we start our own reboot contest, with a jury that only sees after these critirias. And the voters judge the rest ... It would be great if each website after reboot is accompanied with a full report published and archived that is. We could do a contest to find a name for it.
Secondly reboot is also a commercial product which is not really about a democratic voting system, premium registred rebooters get more exposure etcetera.
You could also make guidelines so that any rebooter follows that strictly.
Sorry, comments are closed for this post.