O'Reilly logo

Adding Ajax by Shelley Powers

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Start Clean

Adding Ajax to your site is an opportunity to do that page cleanup you've probably been wanting to do for a long time, but couldn't find the time. Dynamic effects and the use of old and outdated HTML don't go together well, particularly if you're moving objects around, collapsing and expanding columns, or doing in-place editing or help.

In a weblog post at O'Reilly Radar, Nat Torkington wrote the following account of Mark Lucovsky's attempt to implement the same bit of Ajax functionality into two very different web sites; one clean and the other with a large amount of "baggage" (http://radar.oreilly.com/archives/2006/08/the_value_of_web_standards.html:

While at OSCON, Mark Lucovsky of Google sent us a bit of HTML that'd embed a slender map search widget into our conferences web site. It's an easy way for attendees to find restaurants, hotels, parks, bars, etc. near the conference venue. Great idea, and an elegant demo of the Ajax Search API that Mark's been working on.

Mark's next speaking gig was at the Search Engine Strategies (SES) conference, so naturally he reached for the find-me-stuff-around-the-conference example. However, he rapidly ran into the messy HTML that is the SES web site. Whereas it had been a matter of seconds to add the JavaScript into the O'Reilly web page, adding it to the SES page was an ordeal.

That's a vindication of the large amount of hard work that [the] O'Reilly design team put into redesigning pages so they were XHTML and CSS. It's also a vindication of the standards themselves: we sometimes lose track of the bigger picture when we're fighting our way through a twisty maze of namespaces, all alike. The point of the standards is not just to ensure that browsers can display the pages. The standards also ensure the pages form a platform that can be built upon; a hacked-together platform leads to brittle and fragile extensions.

Ajax is heavily dependent on CSS and even more dependent on the DOM. In Ajax applications, we can access individual elements and move them about, create them, or remove them on the fly. Due to the dependency on DOM, we can't just embed script in a page, throw a couple of ID attributes on elements, and expect our effects to work. Ajax is really dependent on the page being clean before we begin.

Before jumping in and tearing web pages apart in order to add Ajax effects, it's a good idea to first run your pages against various validators provided by the W3C (and others) to find and fix the current problem areas. Validation can help you determine how much work your pages need and can help you plan accordingly. Even if you're going to redesign the pages, you'll find that it's easier to convert from one design to another if you start with a clean design.

XHTML and HTML Validators

The granddaddy of all validators is the W3C's Markup Validation Service. To use the validator, enter a URL or upload a web page and the service will list, in minute detail, all those components that aren't valid (or are valid but not encouraged).

The Markup Validation Service supports a variety of doctypes, such as XHTML 1.0 Transitional, HTML 4.01 Strict, XHTML 1.1, and even custom doctypes. Normally a doctype is given in the document, using syntax such as the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

You can override the doctype in the validation service in order to see how the page does with stricter specifications. You can choose to display the source with line numbers (helpful in debugging), or you can specify verbose mode for more detailed output. Figure 1-1 shows the output of the validator, listing several errors.

The W3C's Markup Validation Service tells you how clean your page's markup is

Figure 1-1. The W3C's Markup Validation Service tells you how clean your page's markup is

Another validator is the Total Validator, created by Andy Halford. This validator can take longer than the W3C's, but you have an option (in the Advanced form) of providing an email address to have the results sent to you. The reason Total Validator takes so long is because of its impressive array of options. In addition to validation errors, the site also finds bad or missing links and misspelled words (which can be both localized and customized)—a nice double-check on the site.

One of the options is to check the accessibility of the site, and you can choose from a list of levels, including U.S. Section 508, and the three W3C Web Accessibility Initiative (WAI) levels. Another option allows you to set the number of pages validated (up to 20) and the depth (as defined in the site map). You can also skip specified paths within the site's navigation.

The tool also provides a screenshot based on your browser, operating system, and screen resolution. This is a very handy option if you don't have access to a specific browser in a particular operating system.

Figure 1-2 displays the results of running the validator against the O'Reilly main web page, including a screenshot taken in Konqueror v3.4 in Linux.

Using the Total Validator's many options to closely examine a web page

Figure 1-2. Using the Total Validator's many options to closely examine a web page

CSS Validators

I use Firefox for most of my browsing, and it's also my primary target browser for testing. The reason I use it more than other browsers is because of all the extensions, including those for web developers. Among these is the aforementioned Firebug, which is used extensively throughout this book. Web Developer Toolbar (https://addons.mozilla.org/firefox/60) is another.

Among the features of Web Developer is a drop-down list with various validations that can be run on whatever page you're currently viewing. The HTML option uses the W3C Markup Validation Service, discussed in the previous section. There's also an option to validate the page's stylesheet using the W3C CSS Validator.

The CSS validator accepts the URL of a site or an uploaded file. If you want to try out the CSS before you put it into a stylesheet and you're not sure whether the syntax is valid, you can simply type in the CSS and have it checked. This option is handy—I tried it with the following code, which is from a stylesheet on one of my sites:

.comment-number {
       text-align: right;
       display: inline;
       font-size: 48pt;
       opacity: .3;
       filter: alpha(opacity=30);
       z-index: 3;
       padding-bottom: 0px; margin-bottom: 0px;
}

The result is shown in Figure 1-3. As you can see, the validator rejects the use of the nonstandard opacity settings.

Testing a block of CSS with W3C CSS Validator to see how well it meets the standard

Figure 1-3. Testing a block of CSS with W3C CSS Validator to see how well it meets the standard

Checking Accessibility

Why is accessibility so important? I've heard the argument that only five percent of page readers are impacted by page functionality that may fail these accessibility guidelines. However, ethical considerations aside, accessibility is becoming mandated more and more by law—many countries now mandate that all government pages meet accessibility guidelines. Accessibility is also becoming an important consideration for commercial sites. In fact, there's currently a case pending against Target (a large chain of stores in the U.S. and elsewhere), where the company was successfully sued for not providing an accessible online web store (the case is under appeal). I expect this to be a continuing trend.

Tip

An excellent one-page listing of the best articles on accessibility and Ajax can be found at the Stanford Online Accessibility program at http://soap.stanford.edu/show.php?contentid=65.

Unlike validating CSS or XHTML, determining whether a page meets an accessibility guideline is as much inspection and personal interpretation as it is automated test results. The results from running an accessibility test at the Cynthia Says site can be quite extensive, and you'll probably need to read the guidelines associated with the test. One of the most critical factors in using this site is choosing which standard you're running the test against: one of the three W3C WAI 1.0 guidelines—Priority 1, 2, or 3—or the U.S. Section 508 guidelines.

Tip

Read more on the W3C WAI 1.0 guidelines at http://www.w3.org/TR/WCAG10/, and Section 508 at http://www.access-board.gov/sec508/standards.htm(Subpart_b).

The Total Validator also performs accessibility checks, again providing options for you to choose WAI or Section 508. Even with these tests, though, you'll need to manually check your effort against the guidelines when finished. Something like a meaningful alt attribute description for an image element (which will help readers who can't interpret images to know what's missing) can't be deduced from automatic testing.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required