What Are Web Standards?

Chances are you fit into one of several categories when it comes to authoring documents. You might be a person who uses a visual editor such as Microsoft FrontPage, Dreamweaver MX, or Adobe GoLive exclusively, letting the visual environment guide the markup. Or, you might be specifically a markup author, pounding out your tags and attributes in a text editor such as Emacs, vi, Notepad, or SimpleText. Maybe you like to write your own documents but prefer working with an HTML-style editor such as HomeSite or BBEdit.

As with more and more web professionals, a hybrid methodology may exist for you: you might work using a visual editor and do some hand-authoring, too.

No matter your method, you probably know something about HTML, even if you’ve learned it by viewing source or reading books and have never studied it formally. And, while you might have heard the term web standards, it’s not a very clear term and may have confused you as to what it means and why it’s important.

The term web standard is a confusing one not just because it’s inaccurate, but because it also suggests conformity. I use the term to refer to what is actually a series of specifications and recommendations created by the World Wide Web Consortium (W3C). The W3C is not an authoritative standards body per se. They’re not going to drop by your office and give you a ticket for noncompliance. The primary functions of the W3C are to research, develop, and publish information on technologies and activities related to the Web (see Table 1.1).

Table 1.1: A Sample of Technologies and Activities of the W3C

Technology or Activity	Purpose
Accessibility	To ensure documents are accessible to all people
Cascading Style Sheets (CSS)	To provide a style language for presentation of documents
Document Object Model (DOM)	To provide consistent object models within browsers
Hypertext Markup Language (HTML)	To author web documents
Internationalization	To facilitate proper encoding and display of multilingual and international documents
Synchronized Multimedia Integration	An XML-based language to facilitate multimedia Language (SMIL) synchronization: video, audio, text
Scalable Vector Graphics (SVG)	An XML-based language to facilitate scalable vector-based graphics and animation
Extensible Hypertext Markup	To author documents for the web and alternative devices Language (XHTML)
Extensible Markup Language (XML)	To provide a universal format for structured documents and data
For more specific information related to these technologies, as well as descriptions of the many other issues the W3C concerns itself with, visit www.w3.org/.

When you design your website, no matter which method you use, you are working in part with W3C technologies. And, while the W3C is not an authoritative organization that you must follow, it certainly provides a base from which designers can learn consistent and intelligent practices.

Following a W3C specification—a web standard—does not mean that design options are limited. I suggest the opposite. Innovation requires intermittent periods of stability and chaos. Currently, we are in a transitional time as web professionals. We’re trying to make sense out of the chaos of the past years and achieve some stability in our designs, tools, and methods. It makes sense: we’re looking to find some conventions to make our jobs easier.

Building the next level of the Web’s infrastructure as cleanly as possible provides the matrix for new levels of innovation. I think people are sensing this, and this is why many people are starting to get interested in standards. Web professionals are starting to realize it’s a cool—and necessary—thing to pay attention to in order to keep the technology moving forward in a mature way.

A standards-based site also does not suggest that the site will be unattractive, use text-only, or have few visual elements. In fact, this book exists in part to prove that standards-based sites can not only be attractive, but also downright innovative.

Back to the Future

Most readers are aware of HTML, and many are also aware of its successor in web markup, XHTML.

But where did these languages come from, and how come we’re going through such a radical shift in the way we as designers and developers work?

Let’s begin with the Standardized General Markup Language (SGML). It is what is known as a meta-language. SGML is essentially a massive document type definition (DTD) used to create other markup languages.

Note 

DTDs are plain-text documents that describe the elements, attributes, and other allowed components of a given markup language such as HTML or XHTML, along with its version and type, such as HTML 4.01 Strict. You’ll read more about these distinctions and how they influence your design options later in this chapter.

HTML is derived from SGML. The early use of HTML led to some great and innovative approaches, bending the language to allow for increasingly more complex visual sites. The best—and most problematic—example of this is HTML tables, which were originally added to HTML to manage data tables more effectively than the preformatted text element pre. By turning off table borders, suddenly a de facto grid system for laying out even the most popular site content was born, as you can see in Figure 1.1. As the example shows, the primary site design method became tables.

Figure 1.1: eBay’s Home Page with all table borders turned on

As the examples show, the primary site design method became tables. But tables were problematic for several reasons, including:

• Tables, especially when particularly complex or deeply nested, create overhead in terms of size and speed.

• Complex tables can be difficult to manage, especially across web teams.

• Tables of this nature are often inaccessible to those with visual or mobility-related impairments.

Other problems came to the forefront as various browsers introduced proprietary markup not related to work being done at the W3C. The so-called “browser wars” began in the early 1990s and still exist to a large degree. Browser manufacturers sometimes let corporate agendas get in the way of the greater good. The irony is that the browser manufacturers were (and are now still) members of working groups for standards and yet continue to only slowly implement W3C recommendations while aggressively trying out new technologies in an effort to dominate the browser space.

Not all aspects of the browser wars was bad. In fact, early on, this competition allowed for a time of great innovation. Everyone broke rules: designers, developers, browser and tools vendors. It was an important exercise. However, now the time has come to clean up our practices if we want to move forward in the expanding potential of the web and create a strong, next-level infrastructure.

While these difficult issues in HTML and browser support were being examined, Extensible Markup Language (XML) was coming to light. XML, also derived from SGML, is a more streamlined meta-language that is especially useful for sharing documents and information on the Internet and related networks.

HTML was re-evaluated in the context of XML—with its emphasis on rigor, conformance, and extensibility. This evaluation resulted in the publication of a new markup language, XHTML 1. Introduced in January 2000, XHTML 1 officially replaced HTML 4.01 as the most contemporary available specification. XHTML is now in its 1.1 version, with version 2 on the horizon.

Note 

Just because a specification is currently recommended does not necessarily mean it is the specification with which you must work. In other words, it’s perfectly acceptable to be writing HTML 4.01 instead of XHTML 1.1. The goal is to know the specifications well enough to be able to make decisions about which method will work best for your circumstances.

XHTML is considered by the W3C as a reformulation of HTML as an XML application. XHTML at its most basic is HTML vocabulary in a well-structured XML document. At its most complex, XHTML is extensible and customizable. You’ll read more about this and see examples as you read further in the chapter.

But Why Standards?

So why should you follow standards? A lot of people say, “Hey, I can use nonstandard markup that works just fine.”

There are several reasons why understanding and following standards makes sense. Here are a few:

• You will save time. If your documents follow standards, you achieve a level of efficient work practices. Troubleshooting becomes easier because of document consistency. Team members will work more efficiently in an environment where documents follow structure and logic.

• Saving time means saving money. If you are able to save time by ensuring that your documents are standards compliant, stable, and use CSS for style, you will be able to both profit from the process and pass the resulting savings on to your clients.

• You’ll reduce complicated pages so browsers will interpret and display a page quickly and accessibility concerns will be addressed. This means a happier end user.

• You’ll have better job opportunities. If you are still creating web pages in a visual editor without understanding the underlying markup and have not spent any time studying standards, you are restricting yourself in terms of advancement within the profession.

• You will become part of the solution, not the problem, as the infrastructure of the web becomes increasingly more complex.

• Standards set the stage for extending content beyond the limits of the Web to wireless devices such as smart phones, pagers, and PDAs; alternative devices such as MSNTV (formerly WebTV); and a range of devices yet to come.

To sum up, early case studies suggest that compliance probably saves money for everyone in the website food chain—from site owner to developer to ISP. Those are the immediate advantages. Longer term, working with standards addresses many technical, creative, and even social concerns. Technically, websites will be more easily maintained and also readily available for many platforms beyond the Web. Creatively, you can apply style sheets that will easily make a site look good on a computer screen, on a PDA screen, even in print. Socially, you remove barriers to access by cleaning up your hacked markup and paying attention to accessibility concerns.

Making a Case for Standards: The Web Standards Project

One of the difficulties of becoming familiar with standards is that the W3C tends to focus on the development and creation of technologies rather than the dissemination of educational material related to their work.

The documents at the W3C are often prohibitive for busy people who don’t want to read through the minutia—much less translate clumsy academic writing into useful guidance. The need for more interesting documentation is currently being addressed by the W3C, which has several committees that are working to make their findings more readily understandable and available to the public at large.

In a desire to see the long-term benefits of standards be implemented by browsers, software developers, and designers and developers themselves, a grassroots, volunteer-driven organization called The Web Standards Project emerged. Members of The WaSP (as most people refer to it) work to evangelize standards and educate others about them. The group has recently expanded to include educational initiatives, and its website is an example of an attractive, usable site that adheres to W3C standards and professionally acquired best practices.

The WaSP, however, is a truly independent organization. While understanding the long-term benefits that W3C work does, WaSP members have (and will continue if necessary) to openly criticized certain activities of the W3C. Part of The WaSP mission is to encourage the W3C to live up to its potential.

For more information about The WaSP and its activities, see www.webstandards.org/.

Exploring HTML Concepts

By the time HTML 4 emerged in 1998 as the recommended specification for web markup, a rigorous evaluation had been given to the state of affairs occurring with browsers and language. With HTML 4 came several directives that have shaped the languages that have since evolved and the practices related to those languages. The most critical concerns voiced when HTML 4 was introduced include the following:

• The need to separate document structure and style in order to return documents to a more accessible, cross-platform state. As CSS Level 1 had been completed in 1996, this was a means of encouraging designers and developers to use CSS.

• A desire to improve document rendering.

• A highly motivated need to encourage the authoring of accessible documents.

• The need to encourage web professionals, web development tools manufacturers, and browser developers to adhere to a common base of guidelines.

These critical concepts have followed through to the final version of HTML—HTML 4.01—and beyond, into XHTML.

Note 

TML 4.01 contains only minor editorial changes from HTML 4. It is canonically important, however, because the HTML 4.01 DTDs were used as the basis for XHTML 1. As this discussion progresses, you’ll see examples of HTML 4.01. Most people authoring to standards (and using HTML) use an HTML 4.01 DTD.

The following sections will provide deeper insight into the concerns that HTML 4 raised; this will help you gain a more profound appreciation for how these ideas have influenced the growing interest in using CSS.

Separation of Document Structure and Style

One of HTML 4’s prime directives is to separate document formatting from the presentation of that document. This is a critical issue, because most of the HTML in use today is misused—it’s filled with errors that provide endless problems and make accessibility, document rendering speed, and cross-browser consistency nightmarish to achieve.

What Is Document Structure?

For the purposes of this book, document structure for the purposes of this book is the skeletal structure of a Web document. This skeletal structure includes:

• A DOCTYPE declaration

• An html element

• A head with title

• A document body

• Structural elements only, used in a logical manner for managing content. In this category you’ll find such things as headings (h1, h2, h3, h4, h5, h6), paragraphs and breaks (p, br), and lists (ul, ol, dl).

Note 

DOCTYPE declaration defines the document type and DTD version. DOCTYPE declarations appear at the top of a structured document. These declarations are described in detail in the "Learning About Document Type Definitions" section later in this chapter.

A structured document results in a tree. Listing 1.1 shows a valid HTML 4 document with the required structural components and some content marked up with basic elements.

Listing 1.1: An HTML 4 Document with Basic Structure

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"     "http://www.w3.org/TR/REC-html40/strict.dtd">  <html> <head> <title>Working with Structure</title>   </head> <body> <h1>Welcome</h1> <p>Welcome to the site where structure matters!</p> <h2>Getting Into Structure</h2> <p>In order to begin working with structure, you need to be aware of:</p>    <ul> <li>DOCTYPE declarations</li> <li>Properly structured head and body components</li> <li>Logical structures for content markup</li> </ul> </body> </html>

Figure 1.2 demonstrates the document tree that results from Listing 1.1. Document trees become especially important when working with CSS because of the concept of inheritance—which means style features defined for an element will pass to its children—and how elements are related to one another, influencing the way your style sheets will be interpreted.

Figure 1.2: Document tree with parent, child, and leaf nodes

Documents are broken down into a document root (typically the html element) and any child relationships (the head and body are children to the root, and the body has four children, h1, h2, p, and ul). Finally, there are the leaf nodes: the three bullet items denoted by the li element. Each li element is, of course, a child to the ul element.

Note 

The concept of inheritance is explored in depth in Chapter 2, “Learning CSS Theory.”

Document Presentation

Presentation mostly refers to anything that involves visual details. Examples of presentation include the following:

• Color (see Figure 1.3)

  
  Figure 1.3: The colors in this page are all generated using HTML color attributes

• Text formatting and typographic design (see Figure 1.4)

  
  Figure 1.4: The range of fonts, colors, and sizes in this image are generated by HTML.

• Background graphics (see Figure 1.5)

  
  Figure 1.5: .This early web page still looks great because of its background.

• Borders, padding, spacing (see Figure 1.6)

  
  Figure 1.6: HTML defines the borders, padding, and spacing of page elements.

• Layout of pages (see Figure 1.7)

  
  Figure 1.7: This site uses tables rather than CSS for layout, a common current practice.

HTML 4 was the first HTML version to formally recommend that in its most idealistic expression, authors should leave the HTML document empty of presentational detail and address presentational concerns using—you guessed it—Cascading Style Sheets (CSS).

Note 

One of the greatest features of CSS is that their presentation methods go beyond the screen. You can prepare style sheets so documents can be styled for many types of media, including print, aural devices, PDAs, and cell phones.

Improving Accessibility and Document Rendering

Originally, HTML was designed to be a language that could be easily and readily distributed across various platforms and read by anyone, regardless of their software. But innovation and competition within the browser sector quickly changed that reality. With Microsoft and Netscape Communications Corp. rushing hither and yon to create the coolest technology on the block, the consistency of HTML’s semantic structure was disrupted when new, browser-based tags and attributes emerged—many unsupported by competing browsers. Most of these tags and attributes had to do with presentation or visual design, including Netscape’s renowned blink tag and the dreaded Microsoft IE marquee tag (Figure 1.8).

Figure 1.8: IE’s marquee tag-not only proprietary, but annoying, too.

One of HTML 4’s goals was to bring organization back to HTML. A related goal was to improve accessibility of documents. By using some new element and attribute options within HTML 4, document authors and page designers could now help individuals understand and negotiate pages no matter what their platform—or physical abilities.

Many people with impaired or no vision have tremendous difficulty accessing today’s World Wide Web. This is largely because electronic screen readers that browse the screen and read the content aloud are significantly more challenged by complex graphical pages. However, with a little forethought, authors can make this process much easier. Individuals with other physical limitations are also assisted by devices—and whether it’s a screen reader or special keyboard, the methodologies that HTML 4 proposed to aid access have begun to play a growing role in accessibility and improved rendering of documents.

Accessibility is becoming a hot topic due to recent legislation worldwide that certain kinds of sites must be made accessible to all people, including those with disabilities. In the United States, accessibility has become especially important for federal agency websites as well as those sites created by anyone receiving federal contracts to fund their sites. This is due to legislation regarding accessibility in the U.S.; specifically, it relates to a portion of legislation known as Section 508.

Note 

To learn more about Section 508 and what it details, see www.section508.gov/.

The rendering of documents in a web browser can be improved by adhering to common practices. At its most strict, HTML 4 suggests that the author leave tables behind as a means of presenting layout and instead use Cascading Style Sheets for the positioning of objects on a page. The use of CSS in this way not only improves the rendering of documents within supporting browsers, but it also helps you address accessibility concerns by ensuring that it is the structured document and its content, not the presentation of that content, that gets distributed to those accessing the pages using assistive methods.

The Web Accessibility Initiative (WAI)

The Web Accessibility Initiative (WAI) of the W3C is dedicated to promoting awareness worldwide about accessibility. The WAI provides the following:

• Accessibility guidelines and tips

• Accessibility tests

• Accessibility validation options

• News on accessibility activities

To learn more about the WAI, see www.w3.org/WAI/.

Going Global

Just as access is important to those with disabilities, it is equally important to ensure that multilingual, international, and localized sites can be developed.

To accommodate access for international users, the W3C makes a concerted effort in HTML 4 and beyond to address international issues for authors, user agents, and development tools.

Current areas of activity include the following:

• Increasing awareness among web and browser developers regarding international access issues

• Stressing the importance of Unicode as a mechanism for character encoding

• Creating study groups within the W3C to look at details of international concerns

The importance of internationalization is easily seen with a visit to any multi-lingual website. If you’d like to see a variety of international sites, check out the BBC’s international websites, each written and displayed in a different language, www.bbc.co.uk/.

Note 

For more information on internationalization concerns, visit www.w3.org/International/ .