HTML vs. XHTML

I like to imagine HTML as a laid-back don't-sweat-the-details kind of person. Perhaps not quite as hard-working as XHTML, but much happier and at ease with herself. XHTML, on the other hand is downright uptight. Always vigilant, never taking a rest. Sure, she gets more done, but what a price!

Before I go off the deep end with my personification of Web page code types, let me tell you the specifics. For starters, know that HTML 4 and XHTML 1.0 use precisely the same elements, attributes, and values. The difference is in the syntax.

• Where HTML doesn't care if you use the html, head and body elements, and DOCTYPE, XHTML requires them.

• Where HTML lets you omit some closing tags, XHTML insists on them for every element, even empty ones. For the best compatibility with browsers, add a space and / to empty elements and include an independent closing tag for non-empty elements (Figures 1.251.28). Note that the slash is not strictly valid in empty elements in HTML, though all browsers I've seen simply ignore it.

  Figure 1.25. In HTML, some elements, like p, do not require a closing tag. Subsequent p tags implicitly close earlier ones.

  

  Figure 1.26. In XHTML, all elements must have closing tags.

  

  Figure 1.27. In HTML, empty elements do not have a final slash, though browsers won't complain if they do.

  

  Figure 1.28. In XHTML, even empty elements must have a closing tag. While an independent closing tag for an empty element, like </img>, would be technically correct, adding a space and / to the single img tag ensures compatibility with non-XHTML-savvy browsers.

  

• Where HTML lets you omit quotes around attribute values that contain just letters, numbers and four simple symbols (-, ., _, and :), XHTML gets nightmares (and generates errors) if you leave quotes out (Figures 1.29 and 1.30).

  Figure 1.29. In HTML, attribute values only need to be quoted when they contain spaces or other special characters (anything besides letters, numbers, hyphens, periods, underscores, or colons). So, in this example, only the alt attribute's value must be quoted (though it wouldn't hurt to quote all of them).

  

  Figure 1.30. In XHTML, all attribute values must always be enclosed in quotes.

  

• Where HTML is flexible about case, XHTML is not, demanding that all elements, attributes, and predefined values be in lowercase (Figures 1.31 and 1.32).

  Figure 1.31. In HTML, it doesn't matter if you write element names, attribute names, or predefined values in upper- or lowercase.

  

  Figure 1.32. In XHTML, all element names, attribute names, and predefined values must be written in lowercase.

  

• Where HTML allows you to omit values that have the same name as the attribute, XHTML insists that all values be stated explicitly (Figures 1.33 and 1.34).

  Figure 1.33. In HTML, some attributes, like noshade shown here, don't require any value.

  

  Figure 1.34. In XHTML, attribute values must be stated explicitly. For those attributes that in HTML have no value, simply repeat the attribute's name as its value.

  

What do you get for your troubles?

You might be wondering if it's worth it to worry about every last quotation mark. The answer is, it depends.

XHTML's rigidity affords a lot of advantages. Think of a clean workshop, with hammers and screwdrivers hanging in their places on the wall and all the nuts and bolts in labeled containers. It's so easy to find what you need that it makes projects a hundred times easier. Similarly, XHTML helps you keep your code consistent, well structured, and free of nonstandard tags, which in turn makes it easier to update and edit, to format with CSS, to generate from or convert into a database, and to adapt for other systems, like handhelds.

In addition, XHTML is a logical step in the transition from HTML to XML, since it uses familiar HTML elements and attributes together with modern XML syntax. And since XHTML is the new standard, you can be sure that it will be used with other new and future technologies.

Perhaps one of XHTML's most important gifts is that its insistence on standards makes it more likely to be properly and consistently supported by current browsers, on all platformswhich makes good business sense. And since Web page accessibility is now required by U.S. law, and the laws of many other nations, it is something that should not be ignored. For more information on accessibility laws, visit the W3C Web Accessibility Initiative at http://www.w3.org/WAI/.

For more details about why standards matter, I recommend a trip to The Web Standards Project (http://www.webstandards.org), a consortium of designers turned diplomats determined to end the browser wars, and Jeffrey Zeldman's A List Apart, an excellent online magazine for Web designers (http://www.alistapart.com).