The true selling point of XHTML

by Mads Kristensen 18. February 2007 06:00

Some years ago there was a lot of fuzz about the importance of the W3C XHTML standard. I’ve always been a firm believer of the standards and built every website to comply with them. But why?

Very brief history

The standards have made a huge difference historically speaking, because they helped eradicate browser specific mark-up to such a degree that it today doesn’t really matter if you use Opera, Firefox or IE. The same is true with the CSS standard to some extend. The next releases from the browser manufactures will be even more compliant until they reach ~100% and that is fantastic from a web developer’s point of view.

Strange selling points

Over the years I’ve heard a lot of strange selling points about XHTML, mainly from smaller web design companies. They tell you why they use XHTML and why it is a future proofing feature of their work. Some of these selling points make sense in theory, but is out of touch with the real world. Below are four of those selling points and why they don’t matter as selling points for XHTML.

Separation of content and style

The XHTML 1.0 and the CSS standard made an impact because it let to the separation of content and style. It is easier to maintain a website when the style and content is separated in different files. The same goes with JavaScript. It makes the pages smaller and quicker to download. The funny thing is that you can do that too in HTML 4.01. Smart yes, XHTML future proofing no.

XHTML is XML

One of the biggest lies about future proofing using XHTML is the argument that XHTML is XML.
Because XHTML basically is XML documents it means that those web pages are machine-readable using XPath.

Today, we know that we cannot rely on the XML validity of XHTML documents in general and therefore don’t see them as XML documents suitable for machine parsing. The DOCTYPE tells you one thing, but try to run the validator on an entire website and see how many errors it finds. Normally we use regular expressions to parse XHTML documents when we instead could have used XPath according to the selling point. But of course, we can’t.

Mobile platforms

Another great selling point is that XHTML web pages are readable on mobile devices or take very little modification to be. That was not correct 5 years ago and it still isn’t even though mobile browsers have become much richer such as Opera Mini and Pocket IE.

XHTML is more readable on mobile devices – not because it is XHTML but because its mark-up is simpler. The problem is that in the year of 2007, mobile devices are still terrible at CSS and JavaScript. The autopostback feature of many ASP.NET controls works only in Pocket IE because it uses JavaScript. Changes are that your existing XHTML website does not work on mobile platforms because it is filled with JavaScript and CSS.

The newest standard

XHTML is the newest HTML based standard so it will be easier and cheaper to upgrade to the next standard when it arrives. That’s also a good one. XHTML 1.0 is from January 2000 and has had a small upgrade to XHTML 1.1 a couple of years later. What is the average lifespan of a website compared to the lifespan of a W3C standard? I’ll bet that the website changes before a new standard arrives and even though it arrives before, which browsers will then be ready to fully support it and will it be backward compatible?

Yes, XHTML is the newest standard and it will be cheaper to upgrade, but it doesn’t carry much weight in practice and thereby isn’t future proofing.

The real selling point

So what is the selling point really? If it isn’t the machine readability, the mobile rendering, the newest standard or the fact that you can separate content and style, what then?

The reason I use it is because it has better cross-browser support in the DOM and it look prettier, but is that really a general selling point for an entire standard today? I’m not surprised by all the web developers who don’t care about XHTML when the selling point is so hard to find.

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included

Tags:

Client-side | Random thoughts

Comments

2/19/2007 5:24:19 AM #

 Corey Goldberg

> XHTML is the newest HTML based standard so it will be easier
> and cheaper to upgrade to the next standard when it arrives

though the current work in progress is HTML5.. so XHTML and HTML are going to diverge in the not so distant future.

otherwise, good points.

Corey Goldberg |

2/19/2007 5:52:43 AM #

Mads Kristensen

HTML5 is only in draft at the moment as well as XHTML 2.0. It can take them years to finish I'm sure.

Mads Kristensen |

2/19/2007 10:59:37 PM #

 Capivara

All points are clear to understand and 'really real'.
Congratulations!

PS.
"I’m not surprised by all the web developers who don’t care about XHTML when the selling point is so hard to find."

I'm surprised yes.
With so many information about (X)HTML why not try to use?

Capivara |

2/21/2007 8:27:33 PM #

 Boris Yeltsin

I used XHTML for everything until IE7 came out and still didn't support the right MIME type. I had to serve different pages to different browsers because of that, and it wasn't fun.

This is the single most compelling page against XHTML:
www.elementary-group-standards.com/.../...l-4.html

HTML5 was put forward by an alternate and powerful working group. W3C only just started up a process to look at this - they got a bit scared that the decision was about to be taken out of their hands.

Boris Yeltsin |

2/26/2007 10:07:09 PM #

 David Hammond

Kind of funny that one of your two reasons for using it isn't even true. XHTML does *not* have better cross-browser support in the DOM. It has worse. When you send an XHTML page as text/html, most browsers still follow most of the HTML parsing rules. One such rule that Internet Explorer, Firefox, and Opera happen to follow is that a tr element written as a child of a table element is automatically placed in a tbody. According to the XHTML DTD (which is what the doctype points to) this isn't supposed to happen. One can assume that *some* user agents out there are following the DTD, since in theory they are supposed to. So there's a brand new source of incompatibility.

In fact, XHTML sent as text/html offers absolutely zero benefit in regard to browser support. It only causes incompatibility.

As far as prettiness goes, my HTML is rather pretty. The only real difference is the lack of extra / characters in the tags. Other than that, it's basically identical.

Here's an article I wrote on the problems with using XHTML today: http://www.webdevout.net/articles/beware-of-xhtml

David Hammond |

Comments are closed

About the slave

Mads Kristensen Mads Kristensen
Web developer at ZYB and founder of BlogEngine.NET. More...

LinkedIn ZYB Facebook Last.fm Twitter View Mads Kristensen's profile on Technorati

The Lounge

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008