Webmaster Elitism Part 3 – W3C Compliance

Many webmasters, and site owners make a big deal over W3C Compliance. It is actually an almost meaningless standard for small businesses (and most big ones) – and is always likely to be.

I expect these comments to raise a hailstorm of controversy. But I’ve not written this hastily, and I have the experience to back up what I am saying.

First of all, WC3 standards are created by a group of major players in the web industry. Microsoft is one of them. There are others. They have set standards for code – some of these standards are nothing more than common sense (things that good coders do anyway). They include such things as making sure all tags are closed, and that certain kinds of tags are used to go forward. Others are completely nonsensical, apparently chosen by someone who had the power to say, “That one”.

The original goal was to enhance predictability across browsers. From the beginning, browsers interpreted code differently – and still do in spite of W3C Standards. Web designers have long been counseled to get pages to look GOOD in all browsers, but not to attempt to get them to look identical, because they simply render differently. It was bad enough when web pages were composed primarily of HTML, but now with a high usage of JavaScript, CSS, and other languages, the problem is much more of an issue.

When checking for W3C compliance, gross errors are rarely an issue. I mean, unclosed tags will cause rendering problems, so they don’t usually get past a designer anyway. Huge issues are easy to spot because they cause issues that are visible on the page. But there are a ton of fussy, immaterial little things which do not affect output, do not affect usability, and do not affect anything that matters to anyone, and which can be difficult to solve for a number of reasons.

Site development funds are supposed to be channeled first to areas where the site owner can see an appreciable ROI (Return on Investment). If they cannot, then it should be left out unless a site owner has money to burn and insists. Obsessing about compliance can burn money with no ROI at all.

Now, the real problems come in with four issues:

1. The prevalence of code checkers and buzz about compliance has lead many site owners to believe that somehow their site is superior if it is W3C compliant. Sadly, that isn’t true at all. In fact, a site that passes may be a WORSE site than one that does not, because in general, W3C compliance does not have anything to do with the things that matter most – such as suitable design, readable text, good images, search engine optimization, etc. I’ll repeat that – W3C compliance has NO effect whatsoever on SEO. This means a lot of site owners end up spending extra working out tweaky fussy irrelevant things to make  a site W3C compliant, when in fact, it does nothing to enhance the site at all, in any way that matters. Judging on a basis of site owner ROI (Return on Investment), compulsive adherence to W3C compliance fails to deliver any increase whatsoever in enhanced profitability, but it can end up being more costly to implement. We’ve even had clients who insisted on a W3C compliant template, then went in and edited their own site and inserted non-compliant code, so even if a site starts out that way, it may not stay that way!

2. Browsers are not really W3C Compliant. In fact, Microsoft, one of the players in dictating the standards, consistently produces the LEAST compliant browser! It is clear in release after release, that compliance is not at the top of their list for development, because for every compliance issue they address, they introduce additional non-compliant issues. Microsoft has never been about being a team player, they’ve always been more about perpetuating their own way of doing things – one gets the distinct feeling that they are not on the board to comply with standards agreed upon, but to try to make sure THEIR way of doing things is included in the standard. They display only a token effort toward complying with the standard. If the standard is meaningless to them, then it is pretty well meaningless to anyone else. Because non-compliance by a browser means you CANNOT produce a 100% compliant site and have it function correctly, in many cases. A non-compliant browser may REQUIRE that you use non-compliant code to achieve certain goals. As long as browsers are non-compliant, rigid adherence to the standard is not practical, and in fact, is a little silly. And obsessing about compliance becomes merely a matter of elitism, not a matter of performance or anything else relevant to the ROI for the site owner.

3. The standard is changing. W3C standards are not a “write them once” endeavor. They are constantly evolving, because the code and usage are constantly evolving. And browsers have yet to catch up with the LAST standard, let alone move forward to the next one. This lag and delay means that while the original goal of developing a standard for web code that would enhance predictability across browsers was not a bad one, the practicality of realizing it is an impossibility.

4. Coding is incredibly complex. It is a language. This means that the usage and rules can NEVER be completely defined and absolute, any more than the English language can be. Just as a dictionary is always out of date, and just as grammar rules always have exceptions, and good writers always break the rules, coding rules can never possibly define every conceivable usage or combination. So any attempt to define standards ends up being an exercise in futility long term.

Do I think it is a complete waste of time? Not really. I just think that a healthy dose of common sense needs to be applied! I’ve seen template designers wallowing in apologies over a non-compliant bit of code in their template, when that was the only way they could get IE to behave. And I think it is silly that anyone in the industry would think that an apology was needed at all! I see new site owners running W3C checkers on their site and worrying about the errors, when they should be LOOKING at their site, and worrying about what is on the surface, because that is what their customers are seeing.

• It is possible to produce a site that functions predictably, looks good, works well, and earns money, that is not W3C Compliant – in fact, there are millions of them that do this.
• It is possible to produce a horrid site that is not indexable by search engines, that looks terrible, which customers hate, and which repels every person who visits it and fails to function predictably, and have that site pass the W3C Checkers with flying colors. In fact, there are millions of these out there too.

Code checkers cannot think. They can only look for specific technical issues, some of which matter, some of which do not. They cannot tell what is good, they cannot judge quality. And that is the problem with an arbitrary standard which creates rules, but cannot adjust those rules for practical and realistic situations.

It comes back to the bottom line. If what you are doing does not help the site owner earn better, then there isn’t any point in doing it, no matter how good a coder you had to become to do it. If it works for the intended purpose, it is good. A good coder will already be doing the Compliant things that really matter. Beyond that, they’ll be focusing their efforts where it pays the client to do so.

I anticipate a great deal of disagreement with my points. That is what blog comments are for.