Note: This content is obsolete, and kept for archive purposes only.

This article actually started as a few emails but expanded a bit on the way. The purpose is to inspire the transition towards proper usage of web standards and to help anyone get started. Hey, we all have to start somewhere, nothing is easy in the beginning. Well, maybe eating ice cream, but that is beside the point.

Most of this is already available on the net in some form, written by far more clever people. However, the more information there is, the greater the chance that people will stumble upon it and realize that this web standards thing actually could be worth a closer look.

Desert road The road to web standards can often be long and deserted.


  1. No thanks, I’m just browsing
  2. A long time ago, in a browser far away
  3. The wild web
  4. What are web standards?
  5. XHTML: the new kid on the block
  6. Finding your style using CSS
  7. Cleaning up the table
  8. Dynamic stuff
  9. Meet your DOM
  10. Why do I have to read all this when I use a WYSIWYG editor?
  11. Accessibility
  12. What about Flash?
  13. The bottom line

No thanks, I’m just browsing

The average web site visitor should not need to care about what kind of browser to use, nor the relevance of rendering cascading style sheets in a correct manner. By using web standards we maximize the probability that our sites work satisfactory in most browsers and environments. This is important since the visitor could be using anything from Firefox in high resolution on a Mac to a CAB browser on Atari computers in low resolution, not to mention the increased usage of mobile phones, PDAs and screen readers.

According to research conducted by Web Service Award, ten percent of the population in Sweden has a handicap that results in difficulties following a non-accessible web site. Even though that figure may be exaggerated, everybody knows that a lot of people would greatly benefit from the increased use of web standards.

Especially public service pages should be accessible to everyone, without all the annoying things around. Fortunately a lot of professional sites have realized this and delivers concise content in a fast, accurate and intuitive way.

As the web has evolved from being an entertainment environment by geeks for geeks into an everyday tool for citizens in the time of a decade, there are high demands for usability, security and accessibility. All of this should work satisfactory in all browsers and environments available. Mission impossible? Not at all. Hang up the line to Jim Phelps and tune in on web standards.

A long time ago in a browser far away

Tim Berners-Lee uploaded the first HTML page on August 6, 1991. He also wrote the first web server (httpd) and the first browser (World Wide Web).

Version 1.0 of NCSA Mosaic was released in November 1993. It was the first graphic-oriented browser which reached widespread popularity. One of the developers, Marc Andreesen, started his own company Netscape to develop a new browser. The product was called Netscape Navigator and by the end of 1994 it was the de facto standard among web surfers.

The sleeping giant Microsoft finally woke up and realized the web’s great potential. They licensed the browser Spyglass Mosaic and remade it into Internet Explorer 1.0, released with a Windows 95 feature pack in August 1995. In December 1995, Bill Gates declares the importance of the Internet and Microsoft suddenly turns its attention to the web. This was the starting point of the so called Browser Wars raging from 1996 to 1998.

New versions of Internet Explorer and Netscape Navigator were released in a quick pace, too quick to fix the increasing number of bugs. Mosts aspects were feature-centered and browser-specific techniques started to creep into the world. However, Internet Explorer 3.0 had the first support for CSS and version 4.0 started to run circles around Netscape Navigator. In 1998 Netscape was sold to AOL and Internet Explorer became the dominant browser.

The wild web

A few years after the release of the first graphic browser, people started to browse the web in large numbers. Developers, designers and not least managers saw the business value and started to produce web sites with attractive graphics. This led to increased demand for layout features which naturally made the developers look for technical solutions.

The quick and dirty way was to misuse HTML elements for design, such as creating grids with invisible tables and manage margins by using transparent images (also known as “spacer gifs”). Since HTML was never intended for design, this produced invalid unmaintainable code. Enter the tag soup era.

Amore elaborate path was to create proprietary technology as a way to make people use specific browsers supporting said technology. The teams behind Netscape Navigator and Internet Explorer invented custom techniques to attract users into their products.

These two principles were arguably the major forces behind the commercial breakthrough and brought the internet browsing into public attention. Sadly, it also laid the foundation for a very shaky browsing experience that can still be felt even today. Getting messages such as “Internet Explorer only” or “Netscape only” in your face is getting more uncommon for every day that passes, but it still happens.

I also used to have transitional layout on my pages, such as spacer gifs and multiple nested tables combined with sparse styles. Hey, I even had a blink tag for a brief moment back in 1994 (don’t tell my boss about it). Every time my site went through a major revision I spent sleepless nights on testing the site in various browsers, which often resulted in a lesser appearance with Netscape browsers (there was a time before Gecko and Mozilla).

Then there was light. One of the most important innovations arrived: Cascading Style Sheets, CSS. The specification for CSS1 was released in 1996 with the sequel CSS2 in 1998. It allowed the developer to remove all presentational attributes from the HTML code, letting HTML once more be the structural markup language it was meant to be. But CSS was not an immediate success. The HTML abuse had gotten a firm grip of developers, since it behaved just like the dark side of the Force: Quicker, easier, more seductive.

A few years into the new millennium, considerations of accessibility started to sip into the minds of developers. We’d had many years of Wild West-style on the web, “best viewed” with the most common browser on the most common operating system, not to mention users with disabilities who were effectively shut out from public services as these were becoming more and more online.

Enough of this. Today most serious web developers tend to use a valid combination of markup and style sheets for maximum reliability. The only path to redemption is a universal setup of techniques for creating and viewing web content. Next stop: web standards.

What are web standards?

The commonly used moniker “web standards” is somewhat misguiding. To be more accurate, it is a set of recommendations presented by W3C, thoroughly conceived to offer the best results. Some of these techniques include:

When you develop sites it is highly recommended to validate your design. This can easily be done by using the W3C validation services for HTML and CSS.

XHTML: the new kid on the block

XHTML is not extended HTML, but rather a reformulation of HTML in XML. So what, I hear you exclaim, but bear with me since it is an important difference. It will work in browsers just the same way as HTML do, but it is actually a XML-based markup language with all the extra spice given for free by the world of XML. This is why you have to perform a series of seemingly unnecessary tidbits in converting your old HTML page to XHTML.

For example, in XML all tags must be closed so that goes for XHTML as well. Take for instance the classic <br> element. Empty elements such as this one are fine in HTML, but in XHTML it must either have an end tag or the start tag must end with />. Usually this is written using the minimized syntax <br />.

Another nitpick is case sensitivity. Unlike HTML, XML is case sensitive which means that XHTML is too. So some things must be lowercase, such as element and attribute names. If a tool such as Dreamweaver is used to generate JavaScript stuff, you will have to change the generated names, e.g. OnMouseOver=”” to onmouseover=””.

XHTML works perfectly together with other standards such as CSS and DOM. XHTML is also the current markup standard according to W3C, thus replacing HTML4. For each document there is a DTD, document type definition, controlling the flow. There are three different DTDs (think flavors) of XHTML:

  • XHTML Strict
    This DTD prohibits presentational information. For instance, <p align=”center”> is not valid and the attribute must be moved into the style sheet. Other old-school treats are also invalid. For instance, if you are one of those marauders that enjoy to open up links in new windows, bad luck – the target attribute to the href link is deprecated and cannot be used. The way to do it using XHTML 1.0 Strict goes by the dusty detour of writing some JavaScript.
  • XHTML Transitional
    This is not as strict as Strict (ahem), allowing deprecated elements and attributes. <p align=”center”> is perfectly legal in a transitional document. This tolerable DTD is unfortunately the most popular one since it’s the most forgiving.
  • XHTML Frameset
    This DTD is used when frames are part of the document. But you don’t use frames, do you?

The DTD is specified using a DOCTYPE. This is a declaration at the top of the web page that informs the browser which DTD was used for crafting the markup. For example:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “ xhtml1-strict.dtd”>

This little snippet of code will make the browser render the page as XHTML Strict. Don’t be scared by the goofy syntax, simply cut and paste from the documentation on the W3 site.

Finding your style using CSS

As mentioned earlier, Cascading Style Sheets was a technique invented to improve layout in web documents, instead of using presentational attributes in the markup. It is bandwidth friendly, easy to read and very powerful. Web standards strongly support the separation of structure and presentation. This means that your content should be separated from your design, which is a good thing in many aspects.

For instance, consider the img element. In many browsers, linkable images have a blue border by default. It is quite easy to remove this by using the presentational border attribute like this: <img src=”bob.jpg” border=”0″ />. However, this is a deprecated attribute in favor of style sheets. You can turn off all borders on images by simply adding this rule to your style sheet:

img { border: 0; }

The rules are preferably put in an external file and linked in from the web page. A single edit in that file will affect all pages on the site, which enables very efficient design modification.

If you want a good guide to CSS, check out the book “Eric Meyer on CSS”.

Eric Meyer on CSS My worn copy of Eric Meyer on CSS.

Cleaning up the table

There are several considerations to be made regarding the balance between markup and CSS. One of the most debated is when to use tables. The classic web page layout some years ago was to make extensive use of nested HTML tables and transparent images to set sizes or fill in the blanks.

However, all of that can be done in pure CSS. For instance, the pages of Mink Machine does not contain any layout tables, only tables that are used for presenting tabular data.

Dynamic stuff

During the browser wars, Microsoft created JScript to compete with Netscape’s JavaScript. One of the browser features that helped to increase browser incompatibility was something called dynamic HTML, or DHTML. It was originally a loose marketing term used by Microsoft and Netscape to refer a suite of technologies supported by the fourth generation browsers such as Netscape Navigator 4.x and Internet Explorer 4.x. In practice, it is a simply a combination of HTML, CSS and JavaScript.

But it is not a W3C standard at all. For instance, Netscape Navigator 4.x supported JSS (JavaScript Style Sheets) and Layers (absolute positioned block elements) while Internet Explorer 4.x supported Dynamic CSS and Visual Filters (graphic effects using events), with JavaScript and CSS being the cross-browser technologies caught in the middle. During these times, browsers didn’t support the standard DOM.

Regardless of how to properly name the issue, remember what the red queen said: CSS and JavaScript are good, browser-specific technologies are bad.

Meet your DOM

The Document Object Model, DOM, was a standard developed by W3C to cure the plague of incompatible DHTML that was spreading on the battlefields of the browser wars. The DOM is an object model that provides a standard way for developers to access script objects and presentational layers from the markup. DOM-driven interactivity on a web page can mimic the behavior of desktop software, such as table sorting and panel folding.

For a live demonstration, have a look at my short article Client-side table sorting.

Why do I have to read all this when I use a WYSIWYG editor?

Sometimes people seem to think that web standards enforce boring design. I understand the origin of this misunderstanding but I would say it only depends on who’s doing the site. I’ve seen great designs done using web standard technologies, as well as a lot of ugly things that cannot even spell to “CSS”.

For a beginner, it is easier to achieve a quick and dirty result by firing up Dreamweaver or Flash and start dragging boxes in design mode. At this phase, that approach is faster than writing code in a text editor. However, if you ever considered this approach, please view the generated code from most WYSIWYG tools. It is not exactly poetry.

The support for web standards in WYSIWYG editors is questionable at best. Take Frontpage for instance. It is one of the best-known web editors, even though it’s not a web page editor at all, rather an IE page editor. The software team behind Frontpage were directed to stop working on making it standards-based by orders from Bill himself. The generated markup is littered with things that work best in Internet Explorer, if they work at all.

Dreamweaver is arguably the most popular web page creator available and has a very large user base. Once you get used to Macromedia’s own way of creating user interfaces you’ll discover the reason why Dreamweaver is so loved. It has enough of features to keep you covered for a long time. However, most people probably never look closely at what goes on under the surface of the new shiny web page quickly generated by Dreamweaver.

There is no magic involved, since most web editor software packages try their best to generate code which corresponds to your visual design, based upon a toolbox of techniques (in this case HTML and CSS). For instance, in Dreamweaver there is something called Layer which can be used as a placeholder for other elements and placed anywhere on the page. Under the hood, this Layer thing is simply a HTML <div> element that has been absolutely positioned by using CSS.

As you might have guessed, no one was sleeping in the kingdom of Macromedia. In 2001 the Dreamweaver Task Force was created to work with Macromedia’s engineers to improve the standards compliance of Dreamweaver. The result was Dreamweaver MX, released in 2002. It produces valid markup (if you’re doing the right thing) and has taken a reasonable step forward in using CSS, but there are still some issues regarding positioning. A neat feature is that the backend is composed of XML files which can be modified by the user.


One of the basic principles of the web is that it should be a distribution channel for information, available to anyone anywhere. This is clearly not the case today, even ten years after the popularization.

A lot of developers tend to create web sites that effectively close the door to large groups of people. The problem could be technical (not supporting all browsers and platforms), visual (such as using small fonts or bad contrast which makes the content impossible to read for the visually impaired), physical (such as site requiring a mouse, which requires the user to use one, a struggling experience for a mobility impaired user) and the list goes on. To experience it yourself, try to access the content of your favorite site without using the mouse, while CSS and images are switched off. Can you still navigate and read it?

Ten years ago the web was often considered a playground, but today it is a vital channel for public information and thus it must be available to everyone, disregarding technical and physical abilities. A proper use of web standards will be a great step on the way to make the web accessible to all. Accessibility is empathy toward the users.

What about Flash?

The humble plugin once called FutureSplash was developed to meet the need for embedding vector graphics into a web page. Since the release of version 1.0 in December 1996, it has grown into one of the best-known brands of the web. It was initially used for annoying animations and got a bad reputation among many users over the years. However, if used in a good way, it can create sophisticated web sites with great interactivity thanks to it’s JavaScript-ish control language ActionScript.

Even though Flash is not a recognized W3C standard, it may be used to achieve results not easily attained by HTML. Some things are easier to understand with clean animations rather than a chunk of words. However, one of the biggest issues with Flash is accessibility. For older screen readers, Flash is completely inaccessible. There should always be an option to view a non-flash version of the site.

Back in the early days, Mosaic creators “extended” HTML by adding an <img> element despite W3C’s recommendations to use the <object> element instead. As we all know, <img> prevailed. When Flash entered the market three years later, the W3C still recommended the <object> element, but Netscape created the <embed> element which was naturally adopted by succeeding browsers. The W3C was adamant and left <embed> out of the official HTML specification, which means that still today any site that uses <embed> cannot validate as HTML or XHTML!

But do not despair, there are ways to embed a Flash movie without using the <embed> element. For instance, use Flash satay.

The bottom line

There has been a lot of technical details in this text. My humble advice to web creators out there is to start by thinking on the big picture and user experience.

What is the purpose of your site? How will the users interact with the content? Is the navigation intuitive?

When all concept stuff has settled in your head, the navigation is clear as crystal and you have a vision of your design, the stage is set for detailed thoughts on technical aspects such as how to build it and what tools to use. There’s nothing wrong with having the technical ramifications and pitfalls in mind even during the early design phases, but technology concerns shouldn’t drive design decisions. Do not let your technical knowledge suppress your creative design ideas.


No comments yet.

Leave a reply

Your email address will not be published. Required fields are marked *