Converting to XHTML: Simple Rules, Easy Guidelines
Converting from traditional HTML to XHTML 1.0 is quick and painless, as long as you observe a
few simple rules and easy guidelines. (I really can’t get enough of that phrase.) If you’ve written
HTML, you can write XHTML. If you’ve never written HTML, you can still write XHTML. Let’s zip
through the basics, shall we? Here are the rules of XHTML.
Open with the Proper DOCTYPE and Namespace
XHTML documents begin with elements that tell browsers how to interpret them and validation
services how to test them for conformance. The first of these is the DOCTYPE (short for “document
type”) declaration. This handy little code snippet informs the validation service which version of
XHTML or HTML you’re using. For reasons known only to a W3C committee member, the word
DOCTYPE is always written in all caps—just like your dad’s e-mail messages.
Why a DOCTYPE?
XHTML allows designers/developers to author several different types of documents, each bound
by different rules. The rules of each type are spelled out within the XHTML specifications in a
long piece of text called a document type definition (DTD). Your DOCTYPE declaration tells
validation services and modern browsers which DTD you followed in crafting your markup. In
turn, this information tells those validation services and browsers how to handle your page.
DOCTYPE declarations are a key component of compliant web pages; your markup won’t validate
unless your XHTML source begins with a proper DOCTYPE. In addition, your choice of DOCTYPE
affects the way most modern browsers display your site. The results might surprise you if you’re
not expecting them.
XHTML 1.0 offers three yummy choices of DTD and three possible DOCTYPE declarations:



Transitional—The comfortable, slightly frowsy DTD whose motto is “live and let live”
Strict—The whip-wielding, mysteriously aloof DTD that flogs you for using presentational
markup elements or attributes
Frameset—The one with the 90s haircut; also the one that gives you the ability to use
frames in your design, which comes to the same thing
Which DOCTYPE Is Your Type?
Of the three flavors listed in the previous section, XHTML 1.0 Transitional is the one that’s closest
to the HTML we old-time web designers know and love. That is to say, it’s the only one that
forgives presentational markup structures and deprecated elements and attributes.
The target attribute to the href link is one such bit of deprecated business. If you want linked
pages to open in new windows—or even if you don’t want that but your client insists—
Transitional is the only XHTML DTD that lets you do so with the target attribute:
<p>Visit <a href="http://www.whatever.org" target="_blank">whatever.org</a> in a new
window.</p>
<p>Visit <a href="http://www.whatever.org/" target="bob">whatever.org</a> in a named new
window.</p>
Excerpted from Designing with Web Standards, Third Edition. Zeldman. pp. 113-115.
To open linked pages in new windows under XHTML 1.0 Strict, you would need to write
JavaScript, and you’d also need to make sure the links work in a non-JavaScript-capable
environment. Whether you should force linked pages to open in new windows is beside the point
here. The point is that XHTML 1.0 Transitional lets you do so with a minimum of fuss.
XHTML 1.0 Transitional also tolerates background colors applied directly to table cells and other
such stuff you really ought to do with CSS instead of in your markup. If your DOCTYPE declaration
states that you’ve written XHTML 1.0 Strict but your page includes the deprecated bgcolor
attribute, validation services will flag it as an error—and some compliant browsers will ignore it
(that is, they will not display the background color). By contrast, if you declare that you’re
following the XHTML 1.0 Transitional DTD, bgcolor will not be marked as an error, and
browsers will honor it instead of ignoring it. (See? You’re already beginning to learn how the
presence of a particular DOCTYPE can affect what content is displayed, and how it is displayed, in a
given browser.)
Strict vs. Transitional: The Great Battle of Our Times
Now, few readers of this book—especially of this third edition—have any great motivation to use
the deprecated bgcolor attribute. (You’d only use something like that if you had to support, say,
a large group of Netscape Navigator 3 users, and nobody reading this book should have to do
that.) So why not just use XHTML 1.0 Strict on every project? The answer is, you can—if your
project and process support standards all the way.
XHTML 1.0 Strict is a great choice when you know what you’re doing, have complete control over
your site, and are writing only structural, semantic markup—using CSS for presentation, and
unobtrusive scripting to control behavior.
But Transitional is better when your partners have the ability to ding your beautiful standardsbased canvas. For instance, Transitional may be better when you know that a poorly authored
third-party content feed, such as an advertising or news feed, is going to sully your pristine
structural markup with bad HTML. In 2009, alas, this still happens. Transitional is also a safer
choice when a bad content management system (or a bad job of template integration in a good
CMS) is going to spray your beautiful markup with ugly, invalid HTML. It may also be the best
choice when your site’s editorial staff has the power to dump bad HTML into your beautiful
templates. (Depending on the CMS, and the way permission settings are configured, you can
sometimes prevent Joe the Editor from turning into Joe the Template Butcher.)
To sum up, XHTML 1.0 Transitional is a perfect DTD for designers who are making the transition
to modern web standards (they don’t call it “transitional” for nothing) or when systems and
people beyond your control have the power to damage your work. And Strict is for those who…



Know what they’re doing;
Work to ensure their markup contains only structural and semantic elements—nothing
presentational (no font tags, table layouts, or deprecated presentational elements and
attributes) or behavioral (i.e., no inline JavaScript, no “JavaScript links”); and
Enjoy the luxurious certainty of knowing that their work will not be tampered with by
editors, clients, marketers, standards-unaware CMS systems, and inept future developers.
Excerpted from Designing with Web Standards, Third Edition. Zeldman. pp. 113-115.