Weeding out common web page errors
Creating a browser test suite
Installing multiple versions of Internet Explorer
Catering for unruly web browsers
Common fixes for Internet Explorer bugs
Targeting other browsers with JavaScript

The final test

One time web designers envy designers in other fields is when it comes to testing websites. Although we’re a long way from the “design a site for each browser” mentality that afflicted the medium in the late 1990s, we’ve still not reached the holy grail of “author once, display anywhere.”

The methods outlined in this book take you most of the way there, providing a solid foundation for websites that should need little tweaking to get them working across all web browsers. However, to say such sites will never need any amendments is naïve in the extreme. Therefore, unless authoring for an internal corporate environment where everyone uses exactly the same browser, designers must always ensure they thoroughly test sites in a range of browsers.

Weeding out common errors

Testing in browsers isn’t everything; in fact, you may find that your site fails to work for no reason whatsoever, tear your hair out, and then find the problem lurking in your code somewhere. With that in mind, you should either work with software that has built-in and current validation tools (many have outdated tools, based on old versions of online equivalents), or bookmark and regularly use the W3C’s suite of online tools: the Markup Validation Service (http://validator.w3.org/), CSS Validation Service (http://jigsaw. w3.org/css-validator/), Feed Validation Service (http://validator.w3.org/feed/), Link Checker (http://validator.w3.org/checklink), and others (www.w3.org/QA/Tools/) as relevant.

Other useful online services include WDG Link Valet (www.htmlhelp.com/tools/valet/), WDG HTML Validator (www.htmlhelp.com/tools/validator/), and Total Validator (www. totalvalidator.com/). Accessibility-oriented services include HP’s Color Contrast Verification Tool (www.hp.com/hpinfo/abouthp/accessibility/webaccessibility/color_tool.html); Etre’s Colour Blindness Simulator (www.etre.com/tools/colourblindsimulator/); and the Cynthia Says Portal Tester (www.cynthiasays.com/fulloptions.asp), which can aid you in Section 508 and WAI (Web Accessibility Initiative—see www.w3.org/WAI/) compliance.

Here are some of the more common errors you might make that are often overlooked:

Spelling errors: Spell a start tag wrong and an element likely won’t appear; spell an end tag wrong and it may not be closed properly, wrecking the remaining layout. In CSS, misspelled property or value names can cause rules—and therefore entire layouts— to fail entirely. British English users should also remember to check for and weed out British spellings—setting colour won’t work in CSS, and yet we see that extra u in plenty of web pages (which presumably have their authors scratching their heads, wondering why the colors aren’t being applied properly).

Incorrect use of symbols in CSS: If a CSS rule isn’t working as expected, ensure you’ve not erred when it comes to the symbols used in the CSS selector. It’s a simple enough mistake to use # when you really mean . and vice versa.

Lack of consistency: When working in XHTML, all elements and attributes must be lowercase. In CSS, tag selectors should also be lowercase. However, user-defined id and class values can be in whatever case the author chooses. Ultimately, decide on a convention and stick to it—always. If you set a class value to myvalue in CSS and myValue in HTML, chances are things won’t work. For the record, I prefer lowerCamelCase, but there’s no reason for choosing a particular case.

Not closing elements, attributes, and rules: An unclosed element in HTML may cause the remainder of the web page (or part of it) to not display correctly. Similarly, not closing an HTML attribute makes all of the page’s content until the next double quote part of the attribute. Not closing a CSS rule may cause part or all of the style sheet to not work. Note that CSS pairs that aren’t terminated with a semicolon may cause subsequent rules to partially or wholly fail. A good tip to avoid accidentally not closing elements or rules is to add the end tag/closing bracket immediately after adding the start tag/opening bracket. This also helps to avoid incorrect nesting of elements.

Multiple rule sets: In CSS, ensure that if you use a selector more than once, any overrides are intentional. It’s a common error for a designer to duplicate a rule set and have different CSS property values conflicting in different areas of the CSS.

Errors with the head and body elements: As stated earlier in the book, HTML content should not appear outside of the html element, and body content should not appear outside of the body element. Common errors with these elements include placing content between the closing head element tag () and the body start tag ( ), and including multiple html and body elements.

Inaccessible content: Here, we’re talking in a more general sense, rather than about accessibility for screen reader users. If you create a site with scrollable areas, ensure users can access the content within, even if browser settings aren’t at their defaults. Problems mostly occur when overflow is set to hidden. Similarly, textarea elements that don’t have properly marked-up cols and rows settings will often be tiny when viewed without CSS (these attributes are functional as well as presentational). The same is true for text input fields without a defined size attribute.

Dead links: These can take on many forms, such as a link to another page being dead, an image not showing up, or external documents not being accessible by the web page. If a JavaScript function isn’t working for some reason, try checking to see whether you’ve actually linked it—in some cases, the simpler and most obvious errors are the ones that slip through the net. Also, if things aren’t working on a live site, check the paths—you may have accidentally created a direct link to a file on your local machine, which obviously won’t be accessible to the entire Internet. Spaces within href values or the original file names can also be accidentally overlooked.

Whitespace errors: In CSS, do not place whitespace between class/id indicators and the selector name, or between numerals and units for measurements. However, do not omit whitespace from between contextual selectors, otherwise you’ll “combine” them into a new, probably unknown, one.

Using multiple units: In CSS, a value can only accept a single unit—the likes of 50%px can cause a rule to partially or wholly fail.