If you’ve been on Twitter this morning you’ll have witnessed a bit of a discussion between Remy Sharp and me about his web site http://doesvalidationmatter.com/ which initially just said “no”. I didn’t agree with such a sweeping statement and I still don’t – if you make a statement like that then you need to quantify it. Therefore I called it “arrogant bullshit” which was eloquent enough for 140 characters.
The dangers of influential people making sweeping statements
As Remy and me are friends we just went to IRC and had a longer discussion about what each of us were thinking and I explained in detail the worries I have with luminaries like Remy making a one-off statement like this. I love Remy’s work and I envy his drive and his dedication to the newest technologies out there. That’s why my name is on the back of his and Bruce Lawson’s book where I praised their pragmatism and hands-on examples how to use HTML5 and all its cool APIs in today’s world.
The issue with a statement like “validation doesn’t matter” from someone respected and very much on the forefront of great publications right now is not that it might be wrong or right – it is that people will use it as an excuse without even understanding the subject matter: “Cool, Remy says validation doesn’t matter so let’s use table layouts and font tags – after all they work”.
The issue of validation being of any importance in a web development (and especially markup) context is not easy. The reason is once again the forgiving and undefined environment we as web developers build our products in.
If I put a syntax error in a JavaScript file, it breaks. If I put a syntax error in a PHP script the page doesn’t get rendered (or throws an error). If I write invalid HTML the browser either ignores it or – what is actually worse – tries to fix it for me. This is how browsers always worked as markup is not considered code and this is also why engineers still consider web developers designers. Imagine Word simply replacing everything it considers badly written or a typo when you save and email the document without telling you – this is what browsers do for us.
Markup and validation issues
- Right now we re-invent markup as we want to build real applications rather than simulating them (every Ajax app is a hack, if you really look at it)
- The official validators of the W3C are too strict and outdated
- XHTML was born dead, not because it was a bad idea but because there was no support by the main browser in use at the time
- XHTML2 and XHTML modules reminded me of scribbling of mad men on a prison wall – far too complex for the average mind and trying to solve issues that were either edge cases or just far in the future
- We are used to having to write half-valid code to get things to work and we don’t get any punishment when we write invalid code.
- Flagging up sensible extensions to the HTML namespace like WAI-ARIA as errors and disallowing a site to go live if it doesn’t validate holds us back in building better web applications.
All in all the need for validating markup seems arbitrary and part of an approach to web development that is over. The only time I cared about XHTML was when I had to use XML and XSLT to develop web sites for a certain CMS. I also learnt there that XML providers will never take your data if it doesn’t come with a schema or doesn’t validate. This was just a given.
Neither of the above reasons ever stopped me from writing clean code and validate my HTML. And here’s why:
Validating is part of a process
Validators are brutal and stupid machines. The results should be analysed and applied as they make sense. As Douglas Crockford says about JSLint: “it will hurt your feelings”.
Therefore validators for me are a first step to find and remove obvious flaws. When I was moderator on #html on IRCNet in the long long ago we never helped people who didn’t validate their code – the reason was that 90% of the problems vanished once the persons realised they had forgotten to close a DIV and the browser rendered whatever but not what they intended to get. This allowed us to help far more people with real problems.
Validating markup is the “have you tried turning it off and on again” you do with computers – it will solve a lot of your issues and give you some time to re-think your ways. Furthermore, it solves a lot of issues, some of them magically.
Most of the issues of validation are not about validating or the tools – it is about people misinterpreting the results. As there is such a gap between the standards and what browsers can do some errors being flagged up should be exceptions and not flagged up as show-stoppers.
This has been the bane of accessibility for years – the accessibility standards and validators based on them just spat out reports that people ticked off to abide to a standard and not to build sensible products. Some measures taken to make your site AAA compliant actually made them less accessible. The reason was not that people were such sticklers, the reason was that – at least in England – inaccessible web sites are against the law. So instead of really building accessible products people built sites that validate and stapled the results of an automated validation report to the handover – done.
Which of course is nonsense. You cannot validate semantics and you cannot automatically test if an alternative text for an image really makes sense. For this you need a human to check this. The accessibility standards had that in them. They also asked for testing with users with different abilities, but all of this became not important when you can show a cool report that means your site passed an automated test.
This attitude also spilled out to enterprise environments where the interface of a web app is less important than how it ties in with the business processes. There a validation report from the W3C validator meant the thing goes live or doesn’t. Regardless of what the HTML really is. And these kind of people and the poor developers who had to work for them started the whole animosity towards validation.
Validators check the syntax but not the meaning or the quality of the code. They are the start of a quality process, not the end of it. By saying validation doesn’t matter at all we neuter the whole process.
Let’s educate people about validating and debugging
Instead of telling flat out that validation is dead and we don’t need it we should educate people how to read and weigh validation reports. We should also help the W3C and others to write validators that result in more sensible reports and allow for exceptions and weighing of omissions. Then we have a powerful piece of the puzzle of creating clean, meaningful code.
The siren song of browser support
The bigger confusion about the need or sense of validation is that people say that it works “in all modern browsers” and therefore it is fine to use. The issue with that is that “modern” quickly becomes “holy shit, why did we ever use this” and “nobody uses that one any longer, let’s not support it”. Another issue of course is that if you see a browser as your main support and test platform then it is also up to you to test your code in all the browsers that are “modern” and in all their permutations across different systems.
A lot of the products that now keep us from getting rid of IE6 are the ones that were built back when IE6 was “the awesome” and supporting it was “building for the future”. A lot of what we achieved in the last years and the current communication between browser vendors was based on us fighting for standards support. Let’s be aware of the trap we fell into once and where thinking about standards got us before we condemn the tool that says how far you’ve come close to following a standard that should be the norm.
Remy will publish his thoughts soon, too. This is an interesting discussion. This now was only about validating – the more interesting question is if it is worth it to write valid code. Personally I think browsers have enough on their plate rendering the things we give them – why should they also fix what we did wrong?