XHTML: A MORE "VALID" VALID (PART 3 OF 4)

In general (and, yes, this statement does border on oversimplification), "valid" XHTML documents must be well formed in ways that "valid" HTML documents do not.

This suggests, correctly, that authoring XHTML content is more exacting than HTML.

What first appears to be a burden for web developers is actually a payoff:  it is precisely this higher "standard of validity" that produces in XHTML a more stable document type and, as a result, lends itself to more consistent rendering by browsers.  This is why XHTML documents can be written to operate as well or better than their HTML counterparts when rendered in legacy, current, and new browsers.

Anyone witnessing the "correct" display of a given web page on one browser and the wildly different display of the same page by another browser can attest to the fact that we've reached a point where many pages on the Web contain "bad" HTML markup.

This all-to-common experience is partly due to inconsistent adherence to accepted standards by web developers, but it is also due to lax adherence to standards compliance by some mainstream browsers, which allows non-standard HTML to be processed when it should, by all rights, be rejected.

Depending on your point of view, the "best" browser in the world isn't the one that handles incorrect markup well.  The best browser is the one that rejects any content that isn't standards-compliant.  Of course, we cannot reasonably expect browser designers to actually create client software that is this rigid; on the other hand, embracing the XHTML doctype means we don't have to.

Essentially, XHTML markup requires itself to be standards-compliant.  This results in disciplined content authoring and well-formed documents.  In other words, "valid" XHTML represents a more valid "valid".

PAGE 1  |  PAGE 2  |  PAGE 3  |  PAGE 4