Jump to main navigation, main content

Archived entry | Matt Wilcox .net

Web Standard Design

People have been designing websites since the world wide web got the first graphical browser way back in 1993 (Mosaic, for those who are curious). Back then if you could code HTML, you were a web designer, and that was about all there was to it. Fast forward eleven years to the present day and web design has changed. The wild west years of the world wide web are over, and the cowboys that remain are either holed up in ever more isolated design studios, or are trading in their old-school six shooters and bad attitudes and getting with the times; after all — we are approaching the tail end of 2004 already.

Standards as a concept

Standards are important things. They’re the foundations that allow systems to work properly, without them things start to go wrong. Conceptually there’s nothing to stop you breaking a standard, but if you did it’s likely bad things would happen, which is why it’s often better to think of standards as ‘rules’ than to think of them as ‘guidelines’.
An every day example of the importance of standards would be to look at how the transport system works (sorry, we’re breaking with the cowboy analogy here). Depending on what country you’re in, all cars will drive on either the left or right side of the road. That’s a standard for that country. Any vehicle is perfectly capable of driving on either side of the road, and there is nothing physically to stop them doing so, but if they didn’t obey that standard then accidents would happen, the roads would be blocked and no-one would get anywhere.

The Wild West Web

Everyone knows that websites are written in HTML. What most people don’t realise is that HTML was never meant to be used as it was from around 1994 onward. It was designed to give meaning to blocks of textual data, not to impart visual presentation. A <h1> tag meant ‘this text is the most important heading in the document’. It was the browser that decided to represent that as ‘make this text really big’. A <table> was meant to lay out tabular data, it was never intended to be used as a presentational tool. Yet there wasn’t anything else that a designer could use to change how things looked. In the Wild West Web, tools were limited and the designers only choice was to use many HTML elements in a way they were never designed to be used. This meant that for years, if web designers wanted to indent some text, they wrapped the text in a <blockquote>, whether that text was a quote or not. If they wanted a bullet point in front of a bit of text they just shoved an <li> element in front of that text. If you wanted text to be big you wrapped it in a <h3> tag, whether it was a heading or not.

Working in this way got the job done, but it butchered the meaning behind the document. If you were a person with a disability and using a screen reader, most HTML documents would make no sense whatsoever. Another big problem were the browsers people used to view the web. Most browsers had a shared understanding of how HTML should be rendered, but tended to differ on certain elements, sometimes in subtle ways, sometimes in quite horrible ways. Different browsers rendered text at different sizes, they used different border spacing and padding. Some browsers supported tags that others did not, and some created tags that weren’t even in the HTML specs. Yes, believe it or not but an <img> tag was not originally part of HTML specification, and the <embed> tag never has been, and never will be. The W3C already had an appropriate tag which was designed for inserting multi-media into a document, the <object> tag, but browsers didn’t impliment it. The philosophy of browser makers at the time was that the more unique and advanced features the browser had, the better their chance of getting the dominant market share. This ment browser makers tended to make up things as they went along (e.g. <img> and <embed>) rather than work with what was already there (e.g. <object>), which of course led to ever greated browser incompatabilities. These incompatibilities gave rise to websites proclaiming ‘best viewed in X browser, version Y’. The Wild West Web was a mess in every sense of the word. An expensive to maintain mess at that.

Web Standard Design

Eventually the browser manufacturers and web designers came to realise they needed to make and obey some standards, or else let the web turn into a turgid un-usable quagmire of semi-meaningless code. They finally paid due attention to and worked with the W3C in getting workable standards to the masses. The W3C had been around since 1994, headed by the man who invented the Web in the first place. They had been quietly trying to make standards for half a dozen years, releasing ‘recommendations’ which the browser manufacturers and designers largely ignored. It is only recently that the W3C has started referring to it’s recommendations as ‘standards’, and this turn of events is a Good Thing.
The grim picture painted out above isn’t the same picture web developers look at today. At least, it doesn’t need to be that way. Browsers have come a long way in the last year or two, and are finally supporting Web Standards the way the W3C says they should, and the way they always ought to have. Gone is the need to code multiple versions of a website to cater for each browser, and if you develop with standards compliant code there are a host of advantages:

  • Your site will not just work on ‘that other browser’, it will work properly on any standards compliant device. That means on any browser on any operating system on any device; be that a computer, a PDA, a mobile phone, a brail reader, a screen-reader or anything else. In short, your audience expands, and you’ve only had to write one version of your website
  • In a year or two, when the new browsers are out, your site will still work, exactly as it does now. You won’t need to recode it, and so your site becomes much more future proof.
  • A well coded site using Standards is also backward compatible (to an extent)
  • Your bandwidth needs will probably drop even though your user base goes up. One of the good things about writing good standard compliant code is that it’s actually quite a bit more compact than the old way of doing things.
  • Using Standards based code won’t automatically make your website Accessible, but it goes a long way in paving the path to an accessible site. (An accessible site means the site will be understood and retain full functionality on a variety of browsers and to a variety of people. An accessible site for example allows blind visitors to use the site just as well as a fully sighted person)

As a brief note: It’s now unlawful to make a website which provides a service and isn’t Accessible, as defined in the law. (US Section 508, UK Disability Discrimination Act, RNIB information) While an Accessible website doesn’t have to be one developed with the latest web standards, using web standards most certainly helps. Take a look at the Odeon fiasco for an example of a commercial website that is really suffering because of the old-school way in which it is coded and designed..

The Catch With Standards

Browser support is leaps and bounds above what it was, and is perfectly good enough to be viable today, as the increase in corporations using standards compliant techniques bears out (chevrolet is just one example, microsoft are getting there slowly). Sadly browser support still isn’t perfect. There’s one rather irritating problem: Internet Explorer.
Version 6 of Internet Explorer is a fine browser, but it’s age is well and truly showing. It has a great deal of support for web standards, and plenty to work with, but it is now lagging behind Mozilla, Netscape, Firefox, Safari, Opera, Camino, konqueror, Galeon, and all the other major browsers. The reason Internet Explorer survives is not technical merit, but because it’s the default browser on the majority of PCs and the average Joe doesn’t care to change it for anything else, despite the limitations and the many security vulnerabilities it has.
Oh well, tough luck. A web designers life would be less complicated if IE’s standards support had been updated in the last two years, but it hasn’t, so we have to work around it’s limitations. Fortunately doing that is a whole lot faster and easier than doing things the old way. Most certainly the benefits of designing with web standards far outweigh the minor difficulties such an approach currently comes hand in hand with, and is far preferable to using old, invalid, browser specific design techniques.

Wrapping it up

The web has grown up, and so has the society that uses it. The web is no longer the domain of the nerd, the enthusiast, the well off, the highly educated or the physically able. Todays web user is not part of a niche group of technically adept people, they’re everyone and anyone. Todays web is mature enough to be accessible to everyone using any device that can connect to the net over http, from the person using their PDA over a Wi-Fi hotspot, to the blind person using a screen reader at the library, to your granddad who just got one of those new-fangled computer things in his spare room. These are the people and devices we must now cater for as web developers, and the only tool it makes sense to use is web standards. Without them, you’re denying too many people too much.

From the archives

Other enteries filed under:

Web Development

Site information

Built with valid XHTML and CSS, designed with web standards and accessibility in mind. Best viewed in a modern browser [Firefox, Safari, Opera]

This domain and all content is a copy of my old website, for historical purposes only.