When doing activities that impact the web site presentation of projects I'm involved with, I occasionally hop down to the menu item "Validate Local HTML" in Firefox, a function that is available when you have the web development tools (you can also access it via Ctrl-Shift-A, and of course can always run it directly, but that seemingly tiny improvement in ease and efficiency of utilization can dramatically increase the usage of it). In a weak sort of TDD, it is a constant sanity test of at least the fundamental HTML validity of the generated presentation, and I always strive to get it to the rewarding green no-errors-no-warnings state.
Does it really matter though? Ultimately what really matters is if the site renders as close to as expected as possible in the major browsers, and most of them happily overlook even egregious errors (Internet Explorer was criticized early on for being so forgiving, but given its dominance the other browsers really had no choice but to allow the same sloppiness. Most web publishers weren't about to re-engineer their site just to ensure that it displayed correctly in Opera, for instance.)
Out of curiousity I decided to check some other sites to see how many ensure that their (X)HTML is clean. The following are the results as they stand at this moment, though of course as content is added or removed the state will change (though a clean site is often a clean site with intention, and new content is automatically filtered to ensure that it is pure).
- FAIL - http://www.reddit.com - 36 errors as XHTML 1.0 Transitional. EDIT: Rechecked Reddit, and now it's a PASS
- FAIL - http://www.slashdot.org - 167 errors as HTML 4.01 Strict
- FAIL - http://www.digg.com - 32 errors as XHTML 1.0 Transitional
- FAIL - http://www.cnn.com - 40 errors as HTML 4.01 Transitional (inferred as no doctype was specified)
- FAIL - http://www.microsoft.com - 193 errors as XHTML 1.0 Transitional
- FAIL - http://www.google.com - 58 errors as HTML 4.01 Transitional
- FAIL - http://www.flickr.com - 34 errors as HTML 4.01 Transitional
- FAIL - http://ca.yahoo.com - 276 errors as HTML 4.01 Strict
- FAIL - http://www.sourceforge.net - 65 errors as XHTML 1.0 Transitional
- FAIL - http://www.joelonsoftware.com - 33 errors as XHTML 1.0 Strict
- FAIL - http://www.stackoverflow.com - 58 errors as HTML 4.01 Strict EDIT: Rechecked and now it's a PASS
- FAIL - http://www.dzone.com - 165 errors as XHTML 1.0 Transitional
- FAIL - http://www.codinghorror.com/blog/ - 51 errors as HTML 4.01 Transitional
- PASS - http://www.w3c.org - no errors as XHTML 1.0 Strict
- PASS - http://www.linux.com - no errors as XHTML 1.0 Strict
- PASS - http://www.wordpress.com - no errors as XHTML 1.0 Transitional
(I searched around for more good examples to sit in the PASS category, but sadly they are very few and far between)
Should this be normal?
No, it shouldn't.
Some of the errors in some of the mechanically generated HTML are simply unexcusable, and testify to the general level of sloppiness in the web industry in particular.
Check your HTML. Ensure it conforms to the specs it purports to obey, or accept defeat and step back to a less-demanding level. With tools like one keystroke validation and auto-cleanup HTML Tidy (which is available in module form, allowing you to auto-cleanup content mechanically inline in your site code - see this entry for an example of using Tidy from .NET code), there's simply no excuse.
Many will wave off such criticism, declaring that if it renders fine that's what really matters. Yet the worry about purity has more to do with the code maintenance process, and ensuring that an appropriate amount of care and concern is put into the product, in much the same way that you should strive to have 0 warnings in your projects, even if the compiled output works fine regardless. In the same way that I try (albeit with failures at time) to ensure that I avoid misspellings and typos, even if the message could be successfully conveyed with them.
-Mark
Making better products isn't difficult, and with the horsepower and free software libraries and tools we have available to us, there is no excuse for slacking.
You could make such a claim about virtually any code quality effort. Thankfully most in the industry know that it is a ridiculous, foolish way to approach building a product. Quality does matter.
And making compliant HTML is actually ridiculously easy, so long as it is something you pay a minimum amount of attention to while building, and you don't build up a giant technical deficit and then, finished product in hand, discover that it's grossly divergent.
The most important thing for us has always been to make sure that the site displays well in the suite of most popular browsers, with a secondary concern being the site accessibility and with HTML conformance coming in third.
1) Write HTML that renders properly in all browsers but does not validate.
and
2) Write HTML that validates but won't render properly in Opera or Firefox
Then I will choose 1 every time.
The time that it takes to satisfy both criteria can often be far too high and I'm not setting out to create a web site that validates, I'm creating one that can be used by the largest number of people.
I won't go to a site, check if it validates and then not bother using it if it fails.
I will however go to a site, see that it doesn't work properly in Firefox and move on to a different site.
Valid HTML is a great thing to strive for, but as long as the browsers allow (require) sloppy code then that's probably what they will get.
For sure, there is a very real pragmatism that has to be applied, and cutting what really matters just to get code that validates is not a credible choice.
Looking at many of the deviations from validation on the sites listed, though, and it usually can be chalked up to nothing more than sloppiness. The errors and warnings usually relate to items for which there would be no detriment to cross-browser compatibility if they were fixed (if anything there would be an improvement, and behaviours would be more predictable).
Ultimately it's a goal that is very similar to making clean, properly-commented code: You can certainly make a working, great product without doing so, but with a bit of discipline you can achieve both with no real sacrifice behind care and concern about the product.
PASS - http://london.craigslist.co.uk/ no errors as HTML 4.01 Transitional
PASS - http://wikipedia.org/ no errors as XHTML 1.0 Strict
PASS - http://en.wikipedia.org/wiki/Main_Page no errors as XHTML 1.0 Transitional
Email Address:
(your email address is not displayed)
Website:
Comment *:
Dennis Forbes is a Toronto-based software architect. While focused primarily on the .NET and SQL Server worlds, Dennis frequently ventures outside of this comfort zone into game development and image processing. He has been published in several industry magazines, has been quoted in the Wall Street Journal and has been interviewed by NPR.He is a vice president and lead software architect at an innovative New York City hedge fund back-office services firm.
Dennis has been working on solutions for the financial, telecommunications, and power generation markets for over 15 years.