The road to web standards

Note: Most of this content from 2003 is obsolete, and kept for archive purposes only.

Web standards are a set of technologies from standards organizations such as W3C. The purpose is to make web content as accessible as possible.

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. he 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.

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, a lot of people would greatly benefit from the increased use of web standards.

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.

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

In the beginning

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 Andreessen, 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 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. Most 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” is getting more uncommon for every day that passes, but it still happens.

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. Many users with disabilities were effectively shut out from public services as these were becoming more and more online.

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

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 elaborated to offer the best results. Some of these techniques include:

• Structure: languages such as HTML, XHTML and XML
• Presentation: CSS
• Object models: DOM
• Scripts: ECMA-script/Javascript

Structure with markup

The markup part of your web page is the first thing to consider. XHTML is the current markup standard according to W3C, thus replacing HTML4. XHTML also works perfectly together with other standards such as CSS and DOM.

XHTML is not extended HTML, but rather a reformulation of HTML in XML. 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 elements 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 be closed. 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 Macromedia Dreamweaver is used to generate JavaScript stuff, you will have to change the generated names, e.g. OnMouseOver=”” to onmouseover=””.

For each document there is a DTD, document type definition, controlling the flow. There are three different DTDs 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, such as setting the target attribute to the href link for easy popup misuse. The way to do it using XHTML 1.0 Strict is to write 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:

This little snippet of code will make the browser render the page as XHTML Strict. To get it right, see the documentation on the W3 site.

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

Presentation with 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.

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:

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.

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. But all of that can be done in pure CSS. For instance, the pages of this site does not contain any layout tables, only tables that are used for presenting tabular data.

When you develop sites it is highly recommended to validate your design. This can easily be done by using the CSS validator.

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

My worn copy of Eric Meyer on CSS.

Behavior with scripting

JavaScript is the de facto standard to controlling behavior.

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 DHTML 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.

Document Object Model

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 an example, have a look at my short article Client-side table sorting.

What about WYSIWYG editors?

Web standards does not equal 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 horrible things.

For a beginner, it may be easier to achieve a quick and dirty result by firing up WYSIWYG (what you see is what you get) tools such as Macromedia Dreamweaver, Microsoft Frontpage or even the ancient Netscape Composer. They use the same popular approach as Visual Basic and Borland Builder, making the same user experience as for desktop applications but creating HTML/CSS instead of C/C++. Just drag a few boxes in design mode and the code is instantly generated. At this phase, that approach is likely faster than writing code in a text editor.

Unfortunately the support for web standards in WYSIWYG editors is questionable at best. The generated markup is littered with things that work best in a specific browser.

Dreamweaver is arguably the most popular web page creator available and has a very large user base. However, most people probably never look closely at what goes on under the surface of the new shiny web page quickly generated by the tool.

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 such as 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.

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 often produces valid markup 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.

Accessibility

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 web sites are inaccessible 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 hard to read for the visually impaired), physical (such as site requiring a mouse which could be 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 the information?

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. However, one of the biggest issues with Flash is accessibility. For older screen readers, Flash is completely inaccessible. Search engines may also have a hard time to index the content of a Flash site. 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.

User experience

Modern web development is of course more than just web standards technology. 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.