HTML vs. XHTML: Which is better?

If you are a client-side developer, this question has without a doubt been a topic of discussion. Should you use HTML, or XHTML? Does it matter? The answer is quite verbose, and takes a lot of consideration to determine:

application/xhtml+xml vs text/html

5.1. Internet Media Type

XHTML Documents which follow the guidelines… may also be labeled with the Internet Media Type “application/xhtml+xml” as defined in [RFC3236]…

W3C XHTML 1.0 Guidelines

There are many who feel that an XHTML document without the proper application/xhtml+xml content type is no better than transitional markup, or even tag soup. This is preposterous. First and foremost, content served as application/xhtml+xml will not render in Internet Explorer. The world’s most popular browser will not render this content type. What more do you need to steer clear of this headache?

On the other side of the coin, strict XHTML served as text/html will take advantage of debugging tools (such as validators) to help you code a better page. text/html is allowed per the W3C specifications. It is not meant to be avoided, it is meant to aid your cross-browser needs.

Transitional v. Strict

For all intents and purposes, this is the real question that needs addressing. Not whether you should use (X)HTML, but whether you should use a transitional or a strict doctype. The answer is, and always should be a strict doctype.

In this day and age, it is imperative to think of the transitional doctype as deprecated. Quite honestly, the only thing a transitional doctype is useful for is a false sense of satisfaction when validating your markup. The transitional doctype was created to bridge the switch from HTML to XHTML. It’s treated that way by the W3C, and they go so far as to recommend a strict doctype.

The number one reason you should use strict over transitional is cross-browser compatibility. Believe it or not, the Gecko-based browsers render pages slightly differently when triggered by a transitional doctype. This is called “almost-standards mode”, and is defined in the Mozilla Developer Center documentation.

Using a strict doctype ensures that every browser renders your markup as closely as possible with the standardized specs.

But… my markup isn’t valid in strict mode!

Validity does not equal accessibility. An invalid strict page is always better than a valid transitional, as long as you recognize why it fails validation, and you’ve exhausted all options to correct the markup. True accessibility and semantically correct markup require a separation of content, design, and function. Many of the HTML attributes were created to aid design. Examples are the border, align, width and height attributes. These attributes are deprecated in strict doctypes.

Invalid markup in a strict doctype must be treated as invalid in a transitional doctype, regardless of validation output. HTML is an extremely forgiving language, something you must ignore to better your coding, and to better the web. Consider the error handling in languages such as PHP, ASP and XML. In each, an error will trigger the language to immediately stop rendering until the problem is rectified. There is no option to do otherwise.

Not so with client-side languages. HTML, CSS, and JS all will forgive (and sometimes, forget) errors it receives. This is the way it always will be, because the nature of the web depends on pages rendering despite bad coding practices. The sign of a great front-end developer is the ability to correctly parse the language without the need for error handling.

And so, I submit to you that this:

<ul>
  <li>something
  <li>something else
</ul>

is no better than this (in XHTML):

<br>

is no better than this (in XHTML):

align="absmiddle"

In the end, it is up to the developer to decide which of the two language types is most comfortable. Both have their charm, and both have their acceptable uses. But you must code using a strict doctype. It is the only way to eliminate browser quirks, and it is the best environment you will have to achieve cross-browser optimization.

del.icio.us:HTML vs. XHTML: Which is better?digg:HTML vs. XHTML: Which is better?

One Comment

  1. Gert
    May 21, 2011
    5:04 pm
     

    Wow, that?s a really clever way of tinhinkg about it!

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*