Most of the elements of our design are visible on the screen, from information architecture and design to the graphics. However, dealing with technology usually involves making some invisible decisions that impact the entire design. One of the such important decision is deciding between HTML and XHTML. It is one of those decisions which have to be taken right at the beginning.

XHTML has always been considered as a successor of HTML - a newer model, a new version that improves over the older. Which is what tempted a lot of web people, including yours truly, to start with XHTML. However, as we will see, using XHTML comes with additional responsibility and effort.

What Is XHTML?

You might have come across this question a zillion times before. However, at the cost of repetition, I would like to answer this question again.

XHTML is a family of current and future document types and modules that reproduce, subset, and extend HTML 4 [HTML4]. XHTML family document types are XML based, and ultimately are designed to work in conjunction with XML-based user agents. The details of this family and its evolution are discussed in more detail in [XHTMLMOD].

The X in XHTML stands for ability to extend HTML to make it more functional and interoperative with other markup languages. To be able to do this, XHTML has been based on XML as against SGML.

Pros of XHTML

XHTML derives all the benefits of XML. The important one is that it enforces separation of data and style. This can be done equally efficiently with HTML too. The difference is that XHTML enforces it since HTML is a presentational markup language, where presentational elements are part of the markup.

Another aspect of XML is extensibility. It can mashup with other XML-based markups, like MathML and SVG, and provide a single uniform document. This interoperability between different markups provides for easier automation.The requirement is, as it is with HTML, that it should be associated with the right DTD which can be used for validation.

XHTML has a benefit for developers for debugging. To parse a XHTML document it has to be well-formed XML, that is, it abides by all the rules of XML. This can be helpful for catching errors early in the cycle.

Responsibility with XHTML

XHTML sounds like one the best things to happen. It is true to some extent, but not without more responsibility and effort. The pros of XHTML mentioned will stand good only if

• The strict doctype is used
• It is served as appliction/xhtml+xml

Let me elaborate on both these points.

The Strict Doctype

This point is important even if you decide to use HTML. A doctype is a Document Type Declaration which declares type of the document it resides in. It is metadata about the document that can be used by softwares like browsers and validators to verify if your document is structured the way you have declared it to be. It does so by including path to the intended DTD. This is important because some softwares, like browsers, might change their behaviour depending on this.

Ideally, only the strict doctype would have been enough and it is what is recommended whenever a new web page is designed. An additional transitional doctype is supported for upgrading the legacy web pages to the new standard. Transitional is more lenient as it allows space for upgrades, is inherently temporary and so should not be used for new web designs. However, this has not been heeded well by the community. We have thousands of new web designs which declare themselves to be HTML/XHTML transitional compliant. Roger Johansson has explained nicely difference between the two doctypes.

The application/xhtml+xml media type

W3C has defined certain media types that should be used with corresponding documents in the XHTML family. They are text/html, application/xhtml+xml, application/xml and text/xml. The browser identifies the content type using these and treats the content accordingly. For example, text/html says that the content is html, application/xhtml+xml says that it is XHTMl and so on. text/html is recommended for using with HTML documents and not with XHTML family documents. The application/xhtml+xml is recommended for XHTML documents. So far so good!

The trouble here is that many browsers today, including the widely used Microsoft Internet Explorer do not support this content type. Meaning that if you try to load a XHTML document which is being served as application/xhtml+xml the browser will not understand it and may ask you to save the document. So a lot of XHTML documents today are served as text/html. This makes the browser treat your XHTML document as plain HTML with some incompatibilities. Ian Hickson elaborates on the dangers of serving XHTML documents as text/html.

For designers, XHTML documents that pass validity with being served as text/html can miserably fail when served as application/xhtml+xml. Which means that they are truly not XHTML.

Myths

I have come across certain myths about HTML, XHTMl and CSS.

• HTML does not work with CSS. This is one of the common reasons given for using XHTML. HTML can be used, just that it is easy to not use CSS too, which might break the data-style separation principle.
• XHTML Transitional is better than HTML. Any form of transitional doctype is not good for new web designs. Their intent is to be used with migrating legacy designs, not for anything else. In fact HTML Strict is much better than XHTML Transitional.
• XHTML is just HTML with closed tags. This is used a lot of times to convince others that migrating to XHTML is easy. Syntactially XHTML can be seen as XML applied on HTML, but it is not so. The allowed elements will depend on the doctype used, and the Strict doctype will not allow a lot of HTML elements and attributes. The browsers too treat parsing of CSS and JavaScript differently for HTML and XHTML documents.
• XHTML is stricter than HTML. This is true theoretically, but practially when XHTML is served as HTML this turns into a myth. The only strictness can apply in the well-formedness. Also using the Transitional doctype will allow you to use presentation markup in XHTML, overriding the purpose of XHTML.
• HTML is going to die. This has been busted by the recent news from W3C about parallel HTML and XHTML existence.

Epilogue

Your decision to go with HTML or XHTML should be justifiable. Each have their pros and cons, and migrating either way in the later stage can burn a hole in your client’s pocket. I have faced situations where I wanted to go with HTML, but also wanted to be ready to move to XHTML if required. The meta information can be updated then. However, to make a possible move to XHTML in future easier I have used HTML with closed tags.

Overall, this is a subjective topic and every designer has formed his/her own opinions and conclusions. Somehow I feel that there needs to be best practices or recommended practices for situations like these. Otherwise there might be cases when the standards might just be treated as preferences and make the Web incompatible.

Interesting reading:

• Ten Questions for Tommy Olsson
• Activating the Right Layout Mode
• Bulletproof HTML: 37 Steps to Perfect Markup

Share This

↑ Jump up to the comment form

The posts Competition: Free Ad or Money!, The end of an era for Times New Roman?, Who To Design For?, Are Gradients Great?, The Unknown Blogger and First Impressions, are related to this post.

Or why not take time out to find out about the author of the post.