Think of web standards as an attempt to make the web behave itself. They are a collection of technologies and recommendations designed to increase the chances that a web site will actually work. Not just on the developer’s machine, not just in one blessed browser at one particular resolution, but for as many people as possible.
In barely a decade, the web has gone from an obscure academic curiosity to something ordinary people are expected to use for work, banking, shopping and looking at pictures of other people’s cats. Expectations have risen accordingly.
Visitors may arrive using different browsers, operating systems and screen resolutions. Some use mobile phones or PDAs. Others rely on screen readers and assistive technologies. According to research conducted by Web Service Award, ten percent of the Swedish population has a disability that can make an inaccessible web site difficult to use.
That is a lot of people to tell, effectively, to go somewhere else. Web standards offer a better way. The road to web standards can often be long and tedious.
Web creator Tim Berners-Lee wrote back in 1999: “The web is more a social creation than a technical one. The ultimate goal of the Web is to support and improve our weblike existence in the world.”
The road to web standards can often be long and tedious.
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). A modest beginning for something that would eventually consume vast quantities of human productivity.
Things became more interesting with the release of NCSA Mosaic 1.0 in November 1993. Mosaic was graphical, approachable and enormously influential. One of its developers, Marc Andreessen, went on to start Netscape, whose Navigator browser quickly became the de facto standard of the early web.
Then Microsoft woke up. Internet Explorer 1.0 appeared in August 1995, based on licensed Spyglass Mosaic technology. By December, Bill Gates had publicly recognized that this Internet thing might perhaps amount to something after all, and Microsoft turned the full weight of the company toward the web. The so called “Browser Wars” had begun.
From roughly 1996 to 1998, Netscape and Microsoft hurled new browser versions at each other with impressive enthusiasm and occasionally less impressive quality control. Features arrived quickly. Bugs arrived with them. Proprietary extensions multiplied because apparently the best way to build a universal information system was to make half of it work only in your own browser.
Internet Explorer 3 introduced CSS support. Internet Explorer 4 began running circles around Netscape Navigator. Netscape was sold to AOL in 1998, and Microsoft emerged with the dominant browser. But the still smoking battlefield was littered with deprecated tags, incompatible JavaScript and exhausted developers.
The wild web
WWW officially stands for World Wide Web. For a while, Wild Wild Web would have been equally appropriate.
As graphical browsers became popular, businesses discovered the web and immediately wanted attractive layouts. Developers, being practical creatures with deadlines and clients, found ways to provide them. Unfortunately, HTML had never been designed as a page-layout system. So naturally we used it as one.
The quick and dirty way was to misuse HTML elements for design purposes. Tables were nested inside tables inside other tables. Transparent “spacer” GIFs were stretched into invisible structural beams. Margins were controlled by tiny images. HTML elements intended to describe documents were recruited into service as a primitive desktop-publishing system.
The result became known as tag soup: bloated, invalid, fragile markup held together by habit, browser quirks and the quiet prayer that nobody would ever have to maintain it.
Meanwhile, Netscape and Microsoft invented proprietary technologies to lure developers and users toward their respective browsers. These innovations helped push the web forward commercially, but they also produced years of incompatibility.
“Best viewed in Internet Explorer” and “Netscape required” became two wonderfully efficient ways of saying: Welcome to our web site. Some of you can leave.
Fortunately, things began to improve. CSS1 arrived in 1996, followed by CSS2 in 1998. Cascading Style Sheets offered something almost revolutionary: separate presentation from structure. HTML could describe what the content was, while CSS could decide what it looked like. Developers could finally stop abusing HTML for visual layout.
But old habits are powerful things. Table layouts were familiar, predictable and seductive. Much like the dark side of the Force, they were quicker, easier and came with unpleasant consequences later.
As public services increasingly moved online, accessibility also became harder to ignore. A web site that only worked with one browser, one input device or one set of physical abilities was no longer merely inconvenient. It could prevent people from accessing information and services they actually needed. The web needed common ground.
What are web standards?
The term “web standards” is slightly misleading. What we generally mean is a collection of specifications and recommendations developed by organizations such as the W3C. The basic ingredients are:
Nothing terribly glamorous. No spinning logos. No swooshing intro animation accompanied by techno music. Just a set of agreed rules designed to stop us from making the same page in six different ways.
Structure with markup
Markup is where it begins. XHTML is the current markup standard recommended by the W3C, replacing HTML 4. It works neatly alongside standards such as CSS and the DOM.
Despite the name, XHTML is not simply HTML with additional features bolted on. It is HTML reformulated as XML, which means stricter syntax and fewer opportunities for the browser to politely pretend that your malformed code was what you intended all along.
Each document uses a Document Type Definition, or DTD. The Strict version is preferable when possible. And then there is validation. Do validate your markup. Yes, it can be tedious. Yes, the validator may complain about something you consider utterly harmless. And yes, discovering 47 errors because you forgot one closing tag can produce feelings normally associated with airport security. Do it anyway. The W3C provides validation services that make the process relatively painless.
Presentation with CSS
CSS handles presentation without stuffing visual instructions into the markup itself. It saves bandwidth, makes documents easier to maintain and, once you stop fighting it, is remarkably powerful. More importantly, it reinforces one of the central ideas behind web standards: structure and presentation should be separate concerns.
This becomes particularly obvious when talking about tables. For years, the standard method of building a web page was to construct an elaborate scaffolding of nested tables and transparent GIFs. It was clever in the same way that repairing a car with duct tape is clever: admirable ingenuity, questionable long-term strategy.
Tables still have a purpose. They are for tabular data. They are not supposed to be the steel girders holding your entire web site together. CSS can handle the layout. And while you are validating your markup, validate the CSS as well. The W3C provides a validator for that too.
For anyone looking for a good introduction, Eric Meyer on CSS is an excellent place to start.
Behavior with scripting
JavaScript has become the de facto language for controlling behavior in the browser. Brendan Eich created the first version for Netscape in 1995. Microsoft responded with JScript a year later, because apparently one JavaScript was not enough excitement for everybody.
Then came DHTML. Dynamic HTML sounded impressive, futuristic and vaguely expensive. In reality it was less a technology than a marketing term for combining HTML, CSS and JavaScript to create interactive pages. The trouble was that Netscape and Microsoft had different ideas about how this should work.
But DHTML is not a W3C standard at all. Netscape Navigator 4 offered technologies such as Layers (absolute positioned block elements) and JavaScript Style Sheets (the horror). Internet Explorer 4 had Dynamic CSS and Visual Filters (graphic effects using events). Somewhere in the middle sat JavaScript and CSS, trying to keep the peace while developers wrote browser-detection scripts and quietly reconsidered their career choices.
What was missing was a common object model.
Document Object Model
The Document Object Model (DOM) provides a standard way for scripts to access and manipulate elements in a document. This matters because interactive web pages should not require entirely different code depending on which browser happens to be displaying them.
With the DOM, scripts can manipulate content and presentation in predictable ways, enabling interfaces that behave more like desktop applications: sortable tables, collapsible panels and other interactions that once required browser-specific sorcery.
Standardization may not sound exciting. Neither does indoor plumbing. But you will notice its value when it isn’t there.
WYSIWYG editors
WYSIWYG editors promise an appealing idea: design the page visually and let the software worry about the code. Unfortunately, the code still exists. Somewhere underneath that shiny visual interface is markup, and historically much of the generated code has looked as though it was generated during an industrial accident.
Dreamweaver is probably the most popular web editor available today, and most users will never inspect what it produces beneath the surface. There is no magic involved. Dreamweaver takes visual instructions and translates them into HTML and CSS. Its “Layer”, for example, is essentially a <div> element positioned using CSS.
In 2001, the Dreamweaver Task Force began working with Macromedia to improve standards compliance. 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. But the direction is encouraging, which sometimes is the closest thing we get to victory.
Flash
Flash began life as FutureSplash, a technology for embedding vector graphics in web pages. Since version 1.0 appeared in December 1996, it has become one of the web’s most recognizable technologies.
It first earned a reputation through animations, bouncing logos and interfaces that seemed determined to make users wait a while before being allowed to see what they came looking for.
Even though Flash is not a recognized W3C standard, it may be used to achieve results not easily attained by HTML. With ActionScript it can create rich, highly interactive experiences that are difficult to reproduce using ordinary HTML.
The price is accessibility. Older screen readers may be unable to access Flash content at all, and search engines can have difficulty indexing it. A site built entirely in Flash therefore risks becoming a beautifully animated locked room. Whenever possible, there should be an accessible HTML alternative.
Embedding Flash has its own historical absurdity. Mosaic introduced the <img> element despite the W3C favoring <object>. Netscape later introduced <embed> for plugin content, and browsers adopted it even though it never became part of the official HTML specification. 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 there are ways to embed a Flash movie without using the <embed> element. For instance, use Flash satay.
The web, as always, advances through a delicate combination of standards, accidents and whatever developers discover actually works.
User experience
There is an important danger in all this talk about standards: forgetting the people using the site. Modern web development is more than producing valid XHTML and immaculate CSS.
What is the site for? Can people find what they need? Does the navigation make sense? Does the interface help them, or merely demonstrate how clever the developer is?
Standards are tools, not religion. Passing validation does not automatically make a site useful, attractive or pleasant to use. Technology should support the experience. It should not become the experience.
Accessibility
Accessibility is not merely another box on a developer’s checklist. It is the recognition that there is a human being on the other side of the browser. Accessibility is empathy toward the users.
One of the fundamental promises of the web is that information can be made available to anyone, anywhere. We have not quite delivered on that promise.
Many sites remain inaccessible because they depend on a particular browser, platform, screen size, input device or physical ability. Tiny fonts and poor contrast create problems for visually impaired users. Mouse-dependent interfaces can exclude people with mobility impairments. Badly structured markup can turn a screen reader’s journey through a page into an archaeological expedition.
Try a simple experiment. Take your favorite web site. Turn off images and CSS. Put away the mouse. Can you still navigate it? Can you still understand the content? Can you still use it? If not, something important has been lost beneath the decoration.
Wrap it up
Ten years ago, the web was largely a playground. Today it is becoming infrastructure. Governments, companies, schools and public institutions increasingly depend on it to communicate with people. That changes the responsibility of those building it.
Web standards will not solve every accessibility problem. They will not automatically produce good design, intelligent navigation or meaningful content. But they give us a common foundation.
And perhaps, after years of spacer GIFs, browser sniffing, proprietary tags, nested tables and “Best viewed in…” badges, a common foundation is not such a bad place to start.
Comments
No comments yet.
Leave a reply