Web standards primer
Table of contents | Previous | Next
What are Web standards?
The term Web standards has generally come to refer to the initiative by the World Wide Web Consortium (W3C) and other groups to promote a common set of technical standards and best practices for Web development. The intent is to provide the greatest number of Web users with usable, accessible content in a manner that simplifies the development, maintenance and longevity of Web pages as new browsers are released and updated.
Historically, the problem has been the release of browsers that incorrectly or do not fully support W3C standards. This has given developers and designers a set of unpleasant choices:
In turn, these choices have the following results:
- Create simple pages that use the lowest common subset of standards supported across most browsers.
- Create pages with extraneous markup and code so the page renders as intended across most browsers.
- Create pages for a specific browser or subset of browsers.
Unfortunately, users are impacted most by these issues, particularly those users with special needs or disabilities.
- Pages that lack visual appeal and have limited functionality
- Pages bloated with layers of markup and code that are slower to download and difficult to maintain
- Pages branded with a "best viewed in" caveat (which either advertises the developer's indifference to users with alternate browsers or limited Web development skills)
As you can see by the version numbers on the list above, technical standards are continuously evolving. A Web page doesn't have to to use the latest specifications to be considered "standards compliant." It's also possible to create a Web page that is technically correct according to the specifications, but that violates most if not all Web design best practices.
The technical specifications that comprise Web standards include, but are not limited to, the following:
Just as important as the technical aspect of Web Standards are the best practices.
Separate content from presentation
Chief among the Web design practices is the separation the HTML/XHTML markup of the page from the presentation. The presentation consists of the fonts, colors, page layout, etc., and should be set with an external CSS style sheet. This best practice include the following examples among others:
Why is separating the content from the presentation of a page and using semantic (descriptive) markup a best practice? Web sites that are built this way are much easier to maintain. If the marketing department decides that green is the new black and wants you to update the Web site accordingly, it is much easier to modify an external CSS file than search through all the pages that comprise the site for every tag and change the associated color attribute. An excellent real world example of the power of CSS-based designs is the Web site CSS Zen Garden. Each page of the site uses the same HTML file but achieves a radically different look and feel by referencing a different external CSS file.
- Use of the div tag and CSS instead of tables to layout the design of the page
- Use of the p tag instead of brto create paragraphs
- Use of the strong tag instead of to make text standout
- Use of the em tag instead of i to emphasize text
- Use of heading tags (h1, h2, h3, etc.) to designate headings within the document
Pages that use semantic markup and a CSS-based layout rather than a table-based layout also perform better. Semantic HTML files and their associated style sheet(s) are typically smaller and download faster than HTML files that also contain presentation markup.
Finally, pages that use semantic markup are also easier for machines and developers to read. If the heading of a page is marked up as shown in the following example, the meaning of the markup isn't as clear to a developer who is examining the page as the simple use of an h1 tag would be.
It's also not as clear to search engines or screen readers.
Welcome to River Bend Coffee!
Use a valid DOCTYPE
Another Web Standards best practice is to use a proper document type declaration (DOCTYPE) on your pages. The DOCTYPE is important for a couple of reasons. First, your page won't validate without one. Second, the DOCTYPE tells the Web browser how to render your Web page. Web browsers, with the exception of Opera, have two modes for rendering pages, standards mode and quirks mode. A missing, incomplete, or malformed DOCTYPE causes a Web browser to display a page in quirks mode. A complete, properly formed DOCTYPE triggers standards mode in a browser.
In standards mode, a browser renders a Web page as you designed it, in a standards compliant fashion (more or less). In quirks mode, the Web browser assumes that a Web page is not standards compliant and renders the page as it would have appeared in legacy browsers, before standards specifications existed and were widely adopted. Consequently, you can be less sure of how the browser will display your page when in quirks mode.
The HTML primer of this wiki details proper document type declarations and how to set them in Domino.
Validate your documents
You should always validate your HTML, XHTML, and CSS files. Validation tests markup and CSS documents against the corresponding technical specification for proper implementation and usage. Validation is often a useful method of locating potential issues and ensuring your Web pages will display properly in future browsers.
The W3C provides a HTML/XHTML validation service at http://validator.w3.org and a CSS validation service at http://jigsaw.w3.org/css-validator
A key component of Web standards is accessibility, which ensures that people with visual, auditory, and physical disabilities can navigate and interact with content on the Web. In 1999, the Web Accessibility Initiative (WAI) of the W3C published the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) to provide designers and developers with guidelines on making Web sites accessible.
In 2001, the W3C published the first draft of WCAG 2.0, although it's still in draft form. There has been some criticism of WCAG 2.0, including the length of time it has taken to develop the document. Consequently, a group of developers known as the WCAG Samurai published a set of errata for WCAG 1.0 for use as an alternative to WCAG 2.0.
Despite the debate regarding WCAG 2.0, much of WCAG 1.0 is considered to be the definitive source for accessibility guidelines. The following is a small subset of the guidelines in WCAG 1.0:
It is important to be aware of these guidelines for several reasons. The first and obvious reason is so that Web sites you create are accessible to everyone who wants or needs to access them. The second reason is that there is increasingly a legal obligation to make Web sites accessible. A blind man in Australia successfully sued the Sydney Organization Committee of the Olympic Games in 2000, because the Sydney Olympic Games Web site wasn't adequately usable by blind people. In the United States in 2006, a blind student at UC Berkeley filed suit against the retail chain Target because its Web site was not accessible to blind users. In October 2007, the lawsuit became a nationwide class action.
- Use the alt attribute of the tag to provide a text description of the image
- Do not rely solely on color to convey information (e.g., hyper links should be underlined or somehow visually indicated other than use of an alternate color)
- Do not use tables for layout
- Ensure that background and foreground colors have sufficient contrast
- Use the tag for form controls
The third reason to be aware of these guidelines is so that you can identify what steps you need to take to make a Domino-based Web site accessible. For example, WCAG 1.0 specifies the use of a tag for form controls. The correct markup for an input field called FirstName with an associated label looks like the following example.
However, most Lotus Notes and Domino developers are used to creating fields and labels like those shown in the following figure.
The following HTML is created by Domino 8.0.1 for the field on the form above.
As you can see, the markup does not meet the WCAG 1.0 guidelines. Additionally, most Notes developers use tables to layout the design of a form, placing the field label text in one column and the field in the next. This is fine when developing for Notes clients, but if not adapted for the Web, also violates WCAG 1.0.
If you are new to designing for accessibility, Mark Pilgrim has an excellent guide to making Web sites more accessible at http://www.diveintoaccessibility.org
Application Programming Interface