Some people in the web development/web design/front-end development industry would rather be caught on tape stealing food from small children than admit they pollute the web with websites that do not meet standards when it comes to markup, stylesheet and javascript.
I break these standards on a regular basis, and apparently a lot of other people do as well, according to Opera, only 1 in 25 adhere to web standards, and the rest breaks them in some way. Why is that? Are standards not worth following? My answer is: it depends on the context.
In this post, I will not discuss things such as page size, design from content separation, behaviour from design separation, search engine optimization etc etc, as I believe that all of these can be achieved just as good not adhering to web standards, and that the areas have been dicussed for 5+ years. I would like to focus on things that not so many people talk about when discussing standards; How it affects revenues and the actual organization running a website.
The Business Perspective
Building a new Website / Redesigning a existing one
If you are building a new website, there are few reasons not following standards for css, script and markup. From a technical point of view, there are probably no arguments that are valid for not adhering to standards, but from business point-of-view, there may be some arguments that are valid. These arguments may be:
- Legacy non-standard CMS Software enabling quick time-to-market
- More time efficient development given the teams core comptence
- Alternative Cost, how much do we gain (in money, short and long term) from adhering to standards comparing to not have it as a business requirement.
Running an existing non-standards compliant website
This is where reality hit hard on standard advocates. Converting an existing non-standard-compliant website to a standard-compliant website can be a really daunting job. But it all boils down to technical solutions and a lot of hard work. The real problem is to find the argument, money-wise, to do it. As a businessowner you must ask your self the question: “Why should we use X nr of resources for moving to standards, when we could use the same resources for making our product better?” This is where people who thinks standards are a matter of life and death have to sharpen their arguments. Below I have listed different aspects of a websites function and lifecycle where it is important to understand the conflict between reality and standards.
The Knowledge Perspective
Not all websites are built by people who are educated in web standards. I think that a very common problem with web standards, are the fact that a lot of web-frontends are built by someone who knows their standards and run and maintained by people who do not care or have the knowledge needed to adhere to the standards that the site should support. The big question is again money. How much do we gain, educating people in standards compared to keep the speed up with the current knowledge?
The Web as API Perspective
This is where standards becomes important, in order to expose your web as an API, enabling mashups, this could be done using micro-formats, your own XHTML-schemes or just letting external users grab your content easily and mash it up on their side. Of course a valid XHTML-page will be easier to parse and load as an API, but on the other hand, screenreaders, search engines and other page parsers have been able to grab info even from non-standard supporting websites for a long time, there are even numerous of libraries that lets you do just that. When it comes to the web as API, I believe it is important to focus more on building a website that is API-ified when it comes to url-structure and parameters for responseTypes and locales etc. From this perspective, adhering to standards is of course important, but not adhering to standards is not the same as not being able to expose your web as an API. The only thing you do if you run a website that do not follow standards is making it a tad more difficult for your integrators to mashup your website.
The Accessability Perspective
Accessability and Usability, how do they relate to web standards? There is one argument that everyone is talking about all the time, screen readers. OK, this is close to the above argument. My belief when it comes to this is that a screenreader that can not read non-standard pages, will not be a big success, since a lot of websites, as stated above, do not adhere to standards. Of course a semantic web is easier to understand by machines, and will increase accessability and findability enabling better SEO. As the machines reading the web will become more sophisticated, issues like this is probably a smaller issue in the future, than it is now
The Maintenance Perspective
Some people say that standard based front-ends are easier to maintain. From one perspective I am obliged to agree, web standards fronts are more often separated semantically, css doing design, script behaviour and markup for content. But the separation has nothing to do with standards. One argument could be that if we use standards we do not have to maintain “hacks” in css, script and markup, but as long as you are using components and frameworks you should not have to worry about these things. If everything is a mess with no separation and no standards followed, there may be reasons to change this, if we can find a business argument for it: The cost for moving the web to standards and separation of markup, design and behaviour must be lower than the gains from maintaining a standards compliant product compared to the old solution.
The Code Quality Perspective
Another argument is that standards are better from a quality perspective, that is just noncence. You can build crap with cheap and expensive tools, as well as you can build crap websites with standards and non-standards. You can even build great websites with non-standard solutions.
Conclusion
Standards serve a purpose, they get developers to start thinking how they build things, and slowly they adapt to new patterns and processess building webpages, creating better semantics and separation of design, content and behaviour. Standards are good. But not following them is not the same as doing wrong. There are a number of arguments that may force us to build or keep maintaining products that do not follow standards, often the reason are economical. I believe that in order to be business-oriented all developers have to understand that sometimes the “best” technical solution is not good enough from a business perspective.
Resources
- http://dev.opera.com/articles/view/mama-markup-validation-report/
- http://www.sitepoint.com/blogs/2008/10/17/opera-just-413-of-webs-code-is-valid
- http://dev.opera.com/articles/view/mama/
- http://dev.opera.com/articles/view/mama-key-findings/
- http://dev.opera.com/articles/view/mama-the-url-set/
Good post Mattias.
I think it is good that developers know that its perspective is not the only one that matters. But developers have to (and really only can) decide with technical arguments. The business perspective is just not their job. Not?
Hi,
Thanks for your comment. I do believe that developers that do not understand and drive business will be outsourced to places where programming is cheap. And I do believe that there is a big difference between a programmer and a developer. If I hire a developer I will expect him to actually help driving business and understand what is important for business. If I hire a programmer, I expect him to write code.
I think one major distinction here is first, what are you creating? A web site, or web app?
Creating a website does not require creating a new piece of technology; you leverage existing systems, e.g. Wordpress, Drupal, Joomla, DotNetNuke, or just straight static files. You can choose a system like Wordpress or Drupal and end up with for free a standards compliant web site.
Done. taken care of… standards-compliant web sites, they’re easy.
Creating a web app is different. This is creating a new piece of technology which requires decisions of tools, processes, requirements, etc. I feel that first, if you choose to create a web app that’s simple and focused (which you should do or no one will use it) and choose tools which are focused, flexible and powerful that don’t try to do everything. Assuming that you’ve made these types of decisions would probably mean you’re experienced in dealing with the opposite environment. I feel then you’d be setting yourself up to create a standards-compliant, open, RESTful web app.
The important thing here is be able to say no, the more features you want to add the worse off you’ll be in all aspects of your web app; no one will use it, you can’t be standards compliant, RESTful API-like app will be extremely difficult, and your tool-set will be massive.
If you can’t create a standards compliant web site in 2008, something is wrong; it’s a given with the top tools for creating a web sites and should be a non-decision.
If you’re building a web app, a simple and focused feature and tool-set will lead a more standards-based result.
@Eric Thank for your input.
The article focus on WHEN you will have to make solutions that do not adhere to standards, due to non-technical requirements. This article do not discuss what is the best solution when building a new website or webapp. What I was trying to do was to understand why only 1/25 adhere to standards. The reason as I see it is way beyond technical standard evangelists and naive approaches to web development.
Building stuff from scratch, websites or webapps, is a no-brainer, and adhering to standards is out-of-the-box for 99% of the frameworks you decide to work with.