The road to web standards
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 ladies and gentlemen. However, the more information there is, the greater the chance that people will stumble upon it and realize that this web standard thing actually could be worth a closer look. The audience intended is not the seasoned professionals who write standards related blogs on their own, but rather the other side of the moon.
I often get the impression that a lot of people seem to think that web standards enforce boring design. I understand the origin of this misunderstanding but the truth is this: it only depends on who’s doing the site. I’ve seen kick-ass 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. But then again, a beginner is not the ideal choice for creating a large web site from scratch, unless for educational purposes.
To some readers I may come off as arrogant, laughing at the unfortunate ones that haven’t seen the light yet. In fact, nothing could be further from the truth. Actually, this is all written to encourage people to embrace web standards. Web standards are not a blessing in themselves, but I dare say that they will give you a better understanding of web development. Whether you choose to use it or not, that’s entirely up to you.
- No thanks, I’m just browsing
- A long time ago, in a browser far away
- The wild web
- What are web standards?
- XHTML : the new breed
- Finding your style using CSS
- Cleaning up the table
- Dynamic stuff
- Meet your DOM
- Why do I have to read all this when I use a WYSIWYG editor?
- What about Flash?
- 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 is most likely 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. Yes, ten years ago even I found it amusing with jumping pigs on a web site, but really, there is no need whatsoever for that kind of stuff today on a high traffic information site intended for for public service. You would go there for the quick retrieval of information, not flying pigs (or maybe that’s just me getting older). 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 today higher demands for usability, security and accessibility. All of this should also 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 new 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 way was to abuse HTML elements by using them 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 unreadable code. Enter the tag soup.
The more 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 the road is still long.
I 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 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. However, 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 an entire decade of Wild West-style on the web, best viewed with the most common browser on the most common operating system, not to mention the disabled 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?
First, I would like to say that the commonly used name “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:
- Structure: languages such as HTML, XHTML and XML
- Presentation: CSS
- Object models: DOM
XHTML : the new breed
To put it straight from the beginning: 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 />.
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
- 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. 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 for adding style to web documents, instead of using presentational attributes in the markup code. 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:
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.
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 ten 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.
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?
Well, there are several reasons. First, it’s fun. Second, you might even learn something. Third, support for web standards in WYSIWYG editors are 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 are more or less dumb and try their best to create a backside code which corresponds to your visual design, based upon a toolbox of techniques (in this case HTML and CSS). For instance, in DW 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 problems regarding positioning. A neat feature is that the backend is composed of XML files, that 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 and bad color 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)… The list goes on forever. To experience it yourself, try to access the content of your favorite site without the mouse, and with CSS and images 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 not about producing compliant sites, it’s about empathy toward the users.
What about Flash?
Even though Flash is not a recognised 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, which may cloud your judgment on design choices. My humble advice to web creators out there is this: Start by thinking on the big picture and user experience.
What is the purpose of your site? How will the users interact with the material presented? Does it feel good?
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.