After the browser itself, developers are often very concerned with various technical
aspects supported, the most fundamental technology of being HTML. Despite being the
base technology on which Web pages are built, HTML is actually poorly understood
by a good number of its practitioners. Many commercial editors produce malformed
markup, and tutorials and books on the subject contain numerous and significant
falsehoods. The reason is that the rules of HTML are not enforced, which leads to
complacency on the part of developers. Web browsers are the root of the problem.
Traditionally, browsers have been permissive in what they allowed to render. In fact,
just about anything renders. Go ahead and invent a new element, like
The browser isn’t going to complain when it sees this. Browsers typically aren’t
going to complain if you don’t follow the rules. Forgot to quote your attributes? No
problem. Close tags not used? No big deal. Syntax is not enforced, and when browsers
read pages that have errors, they will make assumptions on how to fix flawed markup
or just plain ignore things they don’t understand. This environment has led developers
to take a loose, browser-focused approach to building Web pages. Unfortunately, HTML
does have rules, and when they aren’t followed, bad things can and do happen. HTML
serves as the foundation of a Web page—if you build on top of shaky foundation, things
are bound to fall down sooner or later. This isn’t idle chatter—once you move to XHTML,
these rules really may be enforced by the browser
Doctypes Regardless of how the browsers have interpreted things in the past, the syntax of HTML and XHTML is now very well defined by a document type definition, or DTD. In fact, all Web pages should begin with a declaration, which is used to indicate the particular version of markup being employed in a page. Table 16-1 shows the most common HTML DTD indicators. You might recall having noticed them at the top of the source of many Web pages.
The doctype defines HTML syntax very carefully. Making sure that a document
complies with the indicated doctype—basically that it follows the rules—is called
validation. Producing valid markup is not a given, and more than a few Web tools
produce invalid markup. Fortunately, many popular Web editors also offer built-in
validation. Online validation is also possible using a site like http://validator.w3.org,
and stand alone validators such as the CSE Validator (http://www.htmlvalidator.com)
are also available. To understand the benefits of validation, consider the HTML shown
here. This example has numerous errors, including proprietary attribute usage, missing
quotes, bad nesting, tags used in inappropriate ways, and tags that aren’t closed.
accomplished through the doctype. The 6.0 versions of the two main browsers now
support both a standards mode and what is known as a quirk mode. The quirk mode
allows for all the various HTML tricks and looseness commonly employed in Web
pages. The browser determines the mode for reading pages by the doctype. Generally,
if the doctype is missing, the browser will enter into quirk mode. Also, if the doctype
indicates an older version of HTML, such as 3.2, is in use, it enters into quirk mode.
However, if a more modern version of HTML is indicated, such as XHTML, the
browser will switch into standards mode. This switch between modes has caused more
than a few headaches for designers who didn’t pay extremely close attention to their
markup. In some instances, the entire box model of the page is disrupted, and visual
distortions can occur—so suddenly the rules really do matter!
Rule: If you use a doctype, specify it correctly and adhere to it
You have to lowercase all tag and attribute names. There’s more, but these are most of them. See the XHTML specification (http://www.w3.org/TR/xhtml1/) for all the rules. Except for a few changes in syntax, like the empty tag changes and the forced lowercase, just do your HTML correctly as you should have done before. While XHTML doesn’t appear to be a big deal, it is. Enforcing rules is going to cause problems, and most pages will have to be restructured somewhat. So the big question is will this really come to pass? If it does, XHTML will probably not sweep the Web in a short period of time. In some sense, the technology should be a big deal, since the payoff of well-formed HTML, actually XHTML, is huge—easier document conversion, improved editors that can generate clean markup, a continued movement towards the separation of Web page presentation from structure, and even automated extraction of content, since pages can be precisely parsed. Yet what will happen when the first XHTML-enforcing browser is released and it doesn’t render 99 percent of the pages on the Net? Browsers already include a compatibility mode for some old markup handled through the doctype switch, as discussed previously. Designers aren’t getting away from old HTML anytime soon. You might call HTML the DOS of the Web, always lurking around some place. However, moving to XHTML is not difficult, and the benefit is great. With careful formatting, normal Web pages can be written to conform to XHTML. and editors should make the job of creating new documents and migrating old ones easier. Suggestion: Conform to XHTML today to “future-proof” Web pages.