A Brief Overview of Web Standards

Most probably you will have heard of the term "Standards" in relation to web sites. We'll start by having a look at what exactly standards are, and what they mean to the Web.

HTML (Hyper Text Markup Language) has been around since the World Wide Web was created. The language was initially designed to mark up a document for a web browser, that is, HTML defines a chunk of text as a paragraph, another as a heading, and another as a link to another document, or it can be used for formatting text, adding underlines, bold areas, and other sections.

As the Internet became increasingly popular, and it became a business in itself, new HTML elements were created to handle graphics and other more presentational elements. This is when the language started to be corrupted by people using it incorrectly. For example, HTML comes with a set of <H1> elements that are used to denote headings in a document. Developers have a tendency to bypass these and, for some strange reason, create a larger text size by using something like <font size="7">. By doing this, the browser has no idea about the structure of the document - all it sees is larger text, not a heading. This is just one example of the corruption that is commonplace in HTML.

When talking about valid code, the emphasis is on creating a page that complies with the W3C standards for that language, whether it is (X)HTML, SVG (Scalable Vector Graphics), XML or one of the many other languages controlled by them. The W3C is the World Wide Web Consortium, http://www.w3c.org, a body that was founded in 1994 by Tim Berners-Lee, the inventor of the Web. The long-term goals of the W3C include making the Web accessible to all, to promote the semantic web and to create a "web of trust". The benefit of writing valid code is that the user agent should interpret the page as the standards dictate. There will always be bugs in browsers but the use of valid, well-written code with (wherever possible) no deprecated elements will mean that a web site will stand a much greater chance of working in as many browsers as possible. It will also remain fairly maintenance-free in years to come as browsers progress and slowly drop support for old code.

There is a lot of emphasis on valid code these days because of the "browser wars" circa versions 3 and 4 of Netscape and IE. We are in a situation today where Internet Explorer is the most used browser, but this wasn't always the case. In the early days of the Internet, Netscape had the edge and were pioneering things such as JavaScript. To try and add value to their browsers, the various manufacturers started adding their own proprietary code such as Internet Explorer's <marquee> and Netscape's <blink> elements. After a few years of this the Web was a mess of lax standards and proprietary insanity, with people more concerned about the look of their page rather than the fact that the code behind it was approaching tag soup. Web developers had to create multiple version of each site and use complex sniffing scripts to redirect users to a version of a site that would work in their browser

Luckily, following the work of such bodies as the Web Standards Project (WaSP, http://webstandards.org), we are in a much better position to starting developing one site that will work in all modern browsers. Developers are starting to take the attitude of "my site will work in all modern browsers, if it breaks, looks like a wreck in your version 4 software, or you only get a degraded presentation, it's your problem, not mine". This is a great step forward which started off with individual blog sites and worked its way up to large organizations such as Lycos and Wired who have both converted to table-less CSS layouts. By this I mean that these sites no longer use tables to construct their pages. The <table> element is a perfectly valid piece of HTML, except that it should be used for the presentation of tabular data rather than to actually structure the layout of a document. With CSS you can position objects themselves rather than having to start building complex nested tables filled with transparent spacer images. Again, this type of design is a corruption of HTML, which is something that, finally, we are getting away from.

"By writing code that complies with the rules and specifications laid down by the W3C, our web sites will be viewable to as many people as possible"

By writing code that complies with the rules and specifications laid down by the W3C, our web sites will be viewable to as many people as possible. As more new methods of accessing online content become available (PDAs, mobile phones, and so on), it becomes increasingly important to ensure that each one of these devices is able to view our content. Coding to standards will help to ensure that everyone should be able to access our information with ease. We'll cover coding for other devices in Chapter 13.

Why Coding to Standards is Important

As we've already mentioned, one of the joys of working on an intranet is that you don't have to worry about whether everything works OK in more than one browser. If it works in yours, it will stand a much better chance of working on everyone else's. Oh quiet and happy life!

If we think about this a little bit more, we'll see that this attitude may be a little misguided. What happens if your intranet has been coded to work explicitly with IE - you've got all those lovely ActiveX controls and filters in place that work wonderfully. Then your boss comes up to you and says that they'd really like to open up part of the intranet to some external clients. Bang - we're back into the realms of cross-browser testing! A company can't turn round to a client and say "well, it's designed to work only on Internet Explorer 6 or above, you'll need to change your browsers to view our site and do business with us".

With the push towards standards-compliance from all corners these days the wealth of code that we can write that will display correctly in all browsers is increasing. If we take a look at the WaSP site (http://www.webstandards.org) which was coded in XHTML and CSS, we can see that it displays correctly not only in modern browsers but also in devices that weren't even considered during the design process such as the Palm Pilot. See the following post at their site for more information: http://www.webstandards.org/buzz/archive/2002_06.html#a000053

"Writing to standards, and using CSS to separate content from presentation, also has the advantage of making your code easier to maintain."

Writing to standards, and using CSS to separate content from presentation, also has the advantage of making your code easier to maintain. In an intranet environment where you know your browser base, you will be fully aware of whether your browser is CSS-enabled and what level of support it has. If you ever have the fear of revisiting a document you haven't touched in a while because it is so full of extraneous code, or you've inherited badly written pages from a previous developer, you should use standards to make your life easier. Using external, linked stylesheets will mean that you can make global changes to the formatting of, for example, your text just by editing the stylesheet. You won't have to visit every single page that requires changing. It also means that when you move to a new job you can leave knowing that whoever follows you won't be cursing you from here to eternity for your bad practices!

This, surely, is the way that we should be moving forward with web development. With the possibility that parts of our intranet could be opened up to clients, it is essential to consider the technologies used when putting your site together.

Future-Proofing Your Code

Hopefully "future-proofing" (also sometimes referred to as forward-compatibility) is a term that you've heard before. Future-proofing is basically ensuring that your code is of a high enough standard to not need constant editing and attention. Browser manufacturers are moving more and more into compliance with the W3C specifications so we can be sure that, as long we are coding to those rather than to any proprietary standards, we won't have too many nasty surprises in the future. An example of this move towards standards can be seen with Internet Explorer's CSS colored scrollbars which Microsoft introduced as a proprietary CSS standard with IE5.5. However, such is the emphasis these days towards standards, that if you try to use these in IE6 in standards mode, IE won't render the color.

By writing to standards and separating as much content from presentation as possible, we can avoid situations in which our intranet fails when future browsers are rolled out across the company. Sleepless nights about whether that integral DHTML menu system will fail or not, are not something that anyone wants. By and large the main browsers are good at supporting the current XHTML standards, although Internet Explorer 6 still doesn't support the entire 4.01 / XHTML 1.0 recommendation.

Note

If you need to check the validity of your HTML or XHTML, then the W3C provides a free validation service at: http://validator.w3.org. If you are using Opera, right-click on any page, then select Frame > Validate Source (or press control+alt+V) and it will automatically upload the rendered version of the page to the validator