The Importance Of Standards Compliance and The Process of Validation
Among the more troubling observations I've made during my studies into web development has been the complete and shameful disregard "web designers" have for standards. This disregard is responsible for accessibility and general usability problems for Internet users. It is also a contributing factor to decreased efficiency of corporate IT departments, not only in terms of repair costs of the general markup when errors are found, but also in terms of the cost of "making it work" on browsers whose manufacturers have long ignored these standards.
Those who choose to ignore the standards established by the Web's standards bodies often provide many excuses about why they do so. What is often overlooked is the understanding that creating standards compliant markup is the primary contributing factor in ensuring overall usability and accessibility. It also facilitates growth of a website in the future and eases the load upon corporate IT departments by making the website easier to maintain.
In order to ensure the quality of their work, developers are best advised to frequently validate their markup using a variety of tools. Doing so will help uncover minor, but important, mistakes in markup. Validation is not a cure-all. "Validated" markup does not necessarily produce well-designed pages and may still be bad in many ways. It can also still render poorly. For this reason, markup should not be "validated" for validation's sake, but as part of the greater quest toward standards compliance and the benefits that this practice brings.
HISTORY OF HTML
In order to understand the importance of standards compliance, we need to understand a little bit about the history of HTML. "Marking Up" a page is an editing practice that dates back long before modern microcomputers. During this process, the publisher makes corrections to the document with marks upon page's text. These days, desktop publishing programs are now able to define two things:
- Procedural Markup, which is concerned with the appearance of text - its font, spacing etc.
- Descriptive or Declarative Markup, which is concerned with the structure or function of the tagged item.
HTML, or "Hypertext Markup Language", and the Worldwide Web, was created by Tim Berners Lee in 1990-1993 and was designed as " ... a way to link and access information of various kinds as a web of nodes in which the user can browse at will." The HTML language, a simplified subset of a more general markup language called SGML, was also created to define the structure of the documents being linked together. HTML was, simply put, a means to define the structure of the text being presented on screen.
Below is one of Tim's earliest HTML documents:
<h1>Links and Anchors</h1>
A link is the connection between one piece of
<a href=WhatIs.html>hypertext</a> and another.
As we can see above, the document is marked with a Title, a Heading, and an Anchor with a Hypertext Reference to another document.
Almost overnight, browser manufacturers started building proprietary "extensions" to the HTML specification. In little more than two years, the proprietary markup supported (nay, encouraged) by Mosaic, Netscape, and Internet Explorer (which was "Spyglass" before being bought by Microsoft) made HTML spin out of control. Initially, "there was nothing in the HTML code itself saying how the text should be displayed and it was left to the web browsers to decide how to render the HTML code." Yet these manufacturers began inserting elements like <img>, <embed>, <object>, <bgsound>, <blink>, and other items that took the focus of HTML away from structure and placed it on presentation. This plethora of new elements has led to interoperability problems for documents across different platforms. It wasn't until the release of the HTML 3.2 specification in 1996 that the Worldwide Web Consortium (founded in 1994) began to exert some control, standardize the language, and took steps to keep it evolving in the right direction.
Something needed to give. If things kept up the way they were going, Netscape and Microsoft would eventually have two completely proprietary versions of HTML, but with no way of supporting the utopian vision of content negotiation. Instead, people would be forced to choose one browser or the other, and surf content specifically created for that platform. Content providers would either have to choose between vendors or spend more resources creating multiple versions of their pages. -- Jeffrey Veen
Still, this seemed to do little to stem what seemed to be an all-out browser war between Netscape and Internet Explorer. Really, the HTML 3.2 spec resembled more of an appeasement of these two tyrants than establishing standards. Many elements named in the HTML 3.2 spec are items that were at one point proprietary in nature. Despite being part of the spec, the browsers often did not support elements that were at one time proprietary to their competitors. The Internet remained a mess despite the new specification.
With the release of the HTML 4.01 specification in 1999, the W3C looks to have actually made real headway toward taking back control over the direction of HTML. This headway includes reverting back to "HTML as structure", with CSS (Cascading Style Sheets) in control of visual presentation. This new spec moves scores of presentational elements and attributes to "deprecated" status.
With the latest HTML spec, the major browser manufacturers have vowed to make greater strides in supporting the latest spec. "Before the year 2000, no browser fully supported W3C recommendations, and we were all taught to write whatever non-valid markup was necessary to make our sites work in these browsers, without even considering the work of the W3C, and its goal of making sites interoperable and accessible to all." Now however, we have a reliable set of standards we can abide by which will "ensure that you use only those elements and structures that are likely to be understood by the widest range of user agents" without worrying that the site will fall apart before the eyes of a visitor using a different browser or even an off-brand browser.
THE IMPORTANCE OF VALIDATION
The root of standards compliance goes full circle back to the originally intended purpose of the Worldwide Web as Tim Berners Lee envisioned it: It is "a way to link and access information of various kinds". Why? So we can just put up pages of text? No, but instead so viewers can access information. The site's visitor is paramount to the success of a website. Despite any delusions that developers have, the visitor is ultimately in control. Those who operate hobby sites may not be as cognizant of this fact, but the many recent failures among e-commerce companies cannot be ignored. Poor usability is frequently cited among the reasons why e-commerce sites will fail. Among usability factors mentioned in success or failure of an e-commerce operation is the site's design. That said, standards compliance is one of many ways to ensure that the site is usable.
Cross Platform Compatibility
A major portion of the code driving a web browsing application is intended to perform the task of recovering from errors in markup. An often-heard argument among those who choose not to author their sites with correct markup is "As long as it renders right on the major browsers, who cares about standards?" The possible responses to this are many. Writing standards-compliant markup should be part of a well thought out strategy intended to help ensure that your site will render properly on any browser that follows the current spec, not just the major browsers. "Why neglect all the other user agents such as text-mode browsers, text to speech synthesizers, search engine spiders and other robots, site analysis tools, etc.?", says Alan Richmond. When your site's markup is valid, you aren't ignoring anyone. Different browsers will cope with markup errors in different ways. Only by adhering to standards can you be assured that no "coping" is necessary.
"Rendering properly in the major browsers" is not an excuse for failing to design to current standards. Simply because the page renders on the screen does not mean that it will do so predictably. This is especially important when you consider the myriad of off brand-browsers. Some designers answer this problem by designing multiple versions of their site or using multiple style sheets. "Creating multiple versions of the same Web page because of incompatibilities among browsers is wasteful and self-defeating for Web developers and their clients. The alternative is to try to resolve the incompatibilities by often complicated workarounds that are costly for developers and their clients - at the cost of preventing Web pages from being flexible enough to be used by emerging technology."
Accessibility
While not currently mandated by law in many countries, accessibility is the law in the UK and Australia, making it all the more possible elsewhere. Developing a standards compliant site is one of the most important steps in ensuring accessibility to disabled visitors. This is due largely in part to the fact that assistive technology is not as forgiving of bad markup as the major browsers. Depending upon the severity of the errors, this may mean complete failure of the page.
Future Growth
Beyond usability, validating your site to current standards will prepare your site for the future. Developing a site that works on today's browsers is by no means an assurance that the site will work in the future. "Validators ensure that your HTML conforms to one of the World Wide Web Consortium recommendations for HTML. Validating is a good habit to get into as it ensures that your pages work on browsers other than those you have "tested" it on, especially those which will come in future, and which may not maintain bugs and general leniency to imperfect HTML which current browsers tend to have." As browser software develops toward closer compliance with the W3C standards, non-compliant sites will have a higher risk of failing to render properly on these new browsers. The larger the website, the greater effort it will take to make the necessary repairs to the site so that it (again) renders as intended. By designing a standards-compliant site, you are preparing for future technology as well as future growth and also facilitating an expansion into the new realm of document markup on the horizon. "Not only will your documents stand a much better chance of being properly displayed in all current and future browsers, but it will be much easier to maintain your documents, or even to convert them from HTML to another markup language such as XML."
Troubleshooting
Finally, validation is a troubleshooting tool. Sending your page through a validator should be the first step toward uncovering the underlying cause between pages that do not render properly. While poor rendering may very well be a buggy browser, in most cases "rendering improperly" usually equals "something is wrong". Validation is one of the ways to uncover exactly what the issue is. By maintaining a standards-compliant site, you are providing yourself with insurance that if something goes awry, you will be able to more easily get to the possible cause.
Adhering to standards is the winning approach
While the old browsers are phased out and newer, more standards-compliant browsers are introduced and grow in marketshare, web developers will need to be mindful of the possible bugs that each of the major browsers may have. That does not mean, however, that valid markup should not be used at every reasonable opportunity. By using proper markup and checking its validity, you are taking steps to ensure the usability, accessibility, and cross-platform compatibility of the site. You are increasing the likelihood that it will be properly indexed by search engines, and are likely to increase the speed at which it renders on all browsers. You are easing site maintenance and at the same time, enabling your site to transition into the future. Adherence to standards is the best decision for a fully functional, growing website.
Notes, Helpful links, and Sources Used
- The Worldwide Web Consortium's Validation Tool
- The Web Design Group's Validation Tool. I particularly like this tool's "Batch Validate" option
- Doctor HTML Validation tool, also has a lot of other features like a link checker, spelling check, and more
- Brief information about Tim Berners Lee, creator of HTML and the HTTP Protocol
- "The Early History of HTML"
- "A History of HTML: Keeping Content and Presentation Separate"
- "The History of HTML"
- A List Apart: "Why Don't You Code For Netscape?"
- "HTML Standards Compliance: Why Bother?"
- Jakob Nielsen's Alertbox: "Did Poor Usability Kill E-Commerce?"
- Creating Accessible Web Pages: "Step 4 - Validating HTML"
- "Why Should You Validate Your Web Pages?"
- About The Australia DDA
- Google Search Results for "failure+e-commerce+usability"
- WASP: "Fighting For Standards"
- "Validation: the key to better style sheet support"
- "Liberty! Equality! Validity!" by CSS Guru Eric Meyer
- "Why We Won't Help You": An article by Mark Pilgrim about the importance of valid markup
- Hixie's Natural Log: "How User Agents Handle Tag Soup"
- RichInStyle's Browser Bugs Information
- HTML Tidy Online Validation/ Markup Fixing/ all-around nifty tool:
This article is free for distribution provided the user gives a link to http://www.karlcore.com on their site.




