(Web) Standards actually do matter a lot

Jan 17 2007 Published by Salvatore Iovene under Software

A week ago I stum­bled upon this arti­cle from Stu­art Brown, which actu­ally even got a fair amount of Diggs. As soon as I read it, I felt obliged to reply exten­sively to it, as I think it mostly rep­re­sent every­thing which is wrong in the cur­rent web design trends (or should I say all time web design trends?).

Some­thing that really annoyed me about the arti­cle, was the lack of seri­ous points and the abun­dance of use­less words like “some stan­dards evan­ge­list”, “Obsess­ing over seman­ti­cally cor­rect markup”, “a few stan­dards zealots”, “zealotry accom­plishes noth­ing but a col­lec­tion of smug faces and a col­lec­tion of ‘XHTML 1.1 Com­pli­ant’ bylines”. Those were only fruit­less diver­sions and not real arguments.

The authors gets one thing right, though, and it’s that

your users don’t care about XHTML, they care about how your site appears.

Alright, we all can agree that most of the aver­age Inter­net users com­pletely ignore every­thing about words like HTML, CSS, JavaScript, PHP and so on. We can’t, at these point blame the users: I don’t know any­thing about the inner work­ings of most of the things I use on a dally basis myself, so no big deal. In spite of this, serv­ing the user is not quite equiv­a­lent to fool­ing him. Giv­ing the user some­thing that actu­ally works, but whose inner work­ings are totally crip­pled, is absolutely wrong. The author of the men­tioned arti­cle fur­ther­more says:

If you can sat­isfy the usabil­ity needs of 100% of your users, yet your code doesn’t val­i­date, then arguably you need do no more.

I’m really strong about my dis­agree­ment here. Val­i­da­tion serves a pur­pose: that is to min­i­mize dif­fer­ences when ren­der­ing the web­site in dif­fer­ent browsers. A well val­i­dated page doesn’t need any guess-based cor­rec­tion by the browser. And Stu­art talks about usabil­ity, whereas a web­site that doesn’t val­i­date will have a harder time in meet­ing usabil­ity require­ments for impaired per­sons. On Feb­ru­ary 2006 there was a story about Tar­get (a retailer), being sued because its pages were unac­ces­si­ble by visu­ally impaired users. The retailer was accused of vio­lat­ing the Cal­i­for­nia Unruh Civil Rights Act, the Cal­i­for­nia Dis­abled Per­sons Act and the Amer­i­cans with Dis­abil­i­ties Act. Need­less to say, the web­site still doesn’t val­i­date (it doesn’t even have a DOCTYPE).

So, why else stan­dards (and espe­cially web stan­dards) are needed?

  1. Stan­dards make it eas­ier for your browsers to ren­der the pages.

    HTML or CSS are, in a way, stan­dards. I.e. a set of rule, meant as a markup lan­guage spec­i­fi­ca­tion, to be fol­lowed in order to design a web page. On top of these spec­i­fi­ca­tions, peo­ple who write browsers have done their work. Unfor­tu­nately, though, not all devel­op­ers are able to, or care to, be strict regard­ing stan­dards. That means that the browsers must have a way to cor­rectly inter­pret some code even though it’s fun­da­men­tally incor­rect. What’s the result of this? Browsers devel­op­ers have to waste time into tak­ing care of cor­rect­ing the mis­takes of web devel­op­ers. This, in turn, gives web devel­op­ers the chance to relax and write worse and worse code. And this makes browsers devel­op­ers’ life worse, and their work slower. In the end the users get noth­ing but worse and worse products.

  2. Stan­dards make life eas­ier for users.

    We can take this off the Web Stan­dards exam­ples, and move to some “real life” cases. Iron­i­cally enough, the other day I was star­ing at my toi­let seat for a while, and noticed that the holes in the toi­let in which you can screw your seat in, are at a fixed dis­tance, and just slightly larger than longer, so to give a lit­tle mar­gin: i.e. if you want to buy a new toi­let seat, the dis­tance between the screws with which you attach it to the toi­let must be between X and X+1 cm. So, when I went to the shop to get a new toi­let seat, I didn’t have to worry about the size. Ven­dors of toi­lets and ven­dors of seat had just agreed on a stan­dard size. The result? No has­sle for the user (me).

  3. Search engines like standards.

    Search engines don’t like find­ing errors. If they have trou­ble pars­ing your pages, they may not get to your care­fully cho­sen key­words, won’t be able to find all those tightly focused meta tags. Your site will be crip­pled on any search engine results page. This is not good. A well designed web­site cre­ates a clear chan­nel, a road map, for search engines, so they know to go exactly where you want them to go and see exactly what you want them to see.

End of the list? Yes. This is all that mat­ters, in the end, to the final user. He doesn’t care how, but in the end he gets bet­ter prod­ucts. Of course there are lots of side effects, e.g.:

  • Stan­dards min­i­mize the dif­fer­ences in the way your pages appear in dif­fer­ent browsers.
  • Stan­dards improve the qual­ity of your code, hence the qual­ity of your product.
  • Code that adheres to stan­dards is eas­ier to maintain.
  • Val­i­dat­ing your code dur­ing the devel­op­ment process eases the dis­cov­ery of flaws and mistakes.
  • Stan­dards increase your value.

Before any­one could say that nobody needs a new arti­cle about web stan­dards, let me remind you that the fol­low­ing web­sites won’t validate:

This means that the standards-aware devel­oper are just a tiny minor­ity. The rest, obvi­ously, don’t think that qual­ity is a good asset for their web­sites. Writ­ing non-validating code is a big step back­wards, on the path of perfection.

Bib­li­og­ra­phy

One response so far