DHTMLdev.com — Dedicated to quality Web development articles and tutorials
The Best Reason to Use XHTML PDF Print E-mail
Tuesday, 07 March 2006

Probably the best reason I have found to use XHTML is when your source code is XML and your output will be HTML. If you will be transforming XML into HTML, you are probably spending way too much time creating and coding in a custom XML language created by you or someone in your group. XHTML, not custom XML, or a hybrid of custom XML/XHTML is what you should be using for your source code.

Related Forum Post

XML and CSS started by Chow.

Why Use XHTML?

XHTML 1.0 Spec

Although dense reading for some people, I highly recommend becoming familiar with the official XHTML 1.0 spec on the W3C Web site.

A common question I hear is "Why use XHTML, why is it so much better than HTML?"

The trouble with this question is the perspective it's coming from. Well, actually, the perspective is fine: there is no solid reason (maybe good reason but not solid) for using XHTML in your Web pages. Of course we should follow W3C recommendations. Of course we should look to the future. Of course we should do a lot things we should do. But then there is the need to just make our code work. So we use HTML tables for layout. We use hacks. We do what it takes to make customers happy and get the job done. And using HTML, not XHTML, in our Web pages is often necessary for various reasons that I will not go into because you know what they are. If you don't know what they are, fine, use XHTML. I wish you would and I hope you can. I fully support the use of XHTML if you can. But some developers cannot. So let's move on and stop judging each other.

Why, then, would/could/should we use XHTML?

Like I said, we have to change our perspective. We should use XHTML instead HTML. Rather, we should often use XHTML instead of custom XML.

If you are writing custom XML for your source documents, just to then transform it into HTML, you have a problem. Why are you doing extra work?

Creating custom XML and coding with it is a lot of extra work. I will go into the details in a moment. But first just let me say this: XHTML could give you all the benefits of XML without the extra overhead of creating a new XML language.

The best reason I have found, in my experience, to use XHTML today, right now, on real projects, is to save time and confusion involved in the extra overhead of creating custom XML.

The Potential Problem with Custom XML

A common strategy to single sourcing content that will be published as HTML is to create a new, custom XML language to describe the content. I cannot tell you how many times I have seen this custom XML: 

 
<doc>
<title>My Title</title>
<para>This is an <bold>example</bold> paragraph.</para>
<list>
<item>First item</item>
<item>Second item</item>
<item>Third item</item>
</list>
</doc>

Before I go into the problems with this XML, let me show you the HTML it would be transformed into: 

 
<body>
<h1>My Title</h1>
<p>This is an <strong>example</strong> paragraph.</p>
<ol>
<li>First item<li>
<li>Second item<li>
<li>Third item<li>
</ol>
</body>

Now that you have seen a very common example of the custom XML I am talking about, I am positive that you can clearly see a number of problems.

Problem #1: Reinventing the Wheel

HTML already defines tags for paragraphs, bold text, headings, and lists, among many other types of content. Why should we define custom XML tags for those same content types, only to then have to write XSL to transform them into HTML? Believe, I did the same thing at one time, until I did it enough to get sick of it, which leads us to problem #2.

Problem #2: Misunderstanding the Purpose of Custom XML

We have all had this mantra drilled into our propeller-geek heads: XML should describe content, not formatting.

Well, that's true, most of the time. But what if the content is a paragraph? Is <p> not descriptive enough? And why would <para> be any better? It is better because it's not <p>? For some reason, we tend to think that as long as the XML tag is not an HTML tag, we have accomplished something as developers.

There exists a false belief that the purpose of XML is to escape HTML. If HTML adequetly describes our content, we do not need to create custom XML elements and attributes. Oh yes, attributes are another part of the story. You know that I have actually seen custom XML like this: 

 
<image file="myfile.gif" />

Why would this XHTML not work? 

 
<img src="myfile.gif" />

Problem #3: We are Making our XSL Overly Complicated

Everytime we write an XSL template to transform a custom XML element like <para> into it's corresponding HTML element like <p>, we are writing XSL we do not need.

The XSL would be much simpler if it could copy whole sections of XHTML code to the output HTML document, rather than having to transform every XML element into an HTML element.

Problem #4: We are Creating Documentation Issues

XHTML is already well documented with a ton of tutorials. So is HTML. Why for the love all that is holy create a custom tagging language that we then have to document and train people on how to use it? If we use XHTML, a large portion of our documentation requirements are done. The documentation issue is especially true for people who do not necessarily know HTML already. If we use XHTML for our XML, then they learn our source code (XHTML) and our published code (HTML) both at the same time. And we do not have to write documentation or training. They can use Google to find their answers.

XHTML Saves XML Development Time

HTML Tidy Converts HTML to XHTML

If you need to convert existing HTML files into XHTML, the best tool, which is also free, for the job is HTML Tidy.

All the issues listed above are evidence of how using XHTML can save development time. Additionally, many times, if custom XML were implemented, the existing HTML code would have to be converted into the custom XML, only to be transform back into HTML later for publication. Hard to believe, huh? But true. I have seen it done many times.

Also, tools and processes have to be created to handle the converion from the existing HTML codebase into the new, custom XML code. It's mindboggling how much development time is wasted.

In addition to the conversion development time, there is also the development time to create tools and processes to transform the custom XML back into HTML, or even if this is new content, to turn the custom into HTML. A lot of development time can be saved if a source document, using XHTML, can just be included in an HTML wrapper template without having to actually transform every source tag into HTML.

Conclusion: Start Thinking about XHTML for Source Content

Many arguments discuss why XHTML should be used in published Web pages. The arguments cite Web standards, which I support. But some developers cannot use XHTML for various reasons. Maybe they do not have good reasons, maybe they do. Let's set that aside as a separate argument and start looking at XHTML in a new way, as an XML language for source documents. The source documents do not even need to be intended for Web publication. XHTML defines a lanugage for describing document structures. If you need an XML language to describe a document, you should consider using XHTML.

Last Updated ( Sunday, 02 April 2006 )
 
< Prev
[ Back ]