XHTML vs. HTML: What Should You Use?

And now an admission. I liked HTML. I thought it was great that you didn't have to obsess over punctuation. Maybe I'm just lazy, but I honestly believe that the Web's popularity is due in part to the fact that browsers cut us all some slack. It made it easy to write Web pages, and so all of us did. Now, a couple of billion pages later, perhaps it's time to change our ways. Or perhaps not. There are a lot of people out there that will tell you that HTML is evil and XHTML is the only solution. I think that's silly. XHTML is a great improvement over HTML. It's stronger, more flexible, more powerful, more likely to be supported in the future, and can be expanded to fit any need. But I'll tell you something. Sometimes you don't need to fill every need. Sometimes, you just want to publish a simple page without stressing over every last quotation mark. Luckily there is a lot of middle ground. There are actually three standard flavors of both HTML and XHTML. The first, called transitional, allows the use of the deprecated tags. The second, called strict, prohibits the use of any of the deprecated tags. The third flavor, frameset, allows both the use of deprecated tags and the use of frames, which have fallen into such disfavor that I've moved the chapter that describes them out of the book and onto my Web site (. You can combine each of these flavors in varying degrees with CSS. Which combination you choose may depend on several factors. (Keep reading.) Deciding between HTML, XHTML, and CSS: While I don't recommend using proprietary extensions since they leave out part of your audience there are a lot of other options. Here are some guidelines. The bigger the site, the more important it is that you use CSS and XHTML. The former makes it easy to apply, edit, and update formatting across the entire site; the latter gives your page the structure it needs to make sure it lasts into the future. Many companies and government agencies, including the U.S. government, require that your Web page fulfill specific accessibility requirements in order to make their sites available to people with disabilities. In these cases, you should adhere as closely as possible to XHTML strict, with CSS for formatting. And be sure to check the company's or agency's pertinent guidelines for details in your particular case. Large commercial sites that want to reach the widest audience may opt for transitional XHTML, taking advantage of some deprecated tags' practically universal support, while banking on XHTML's rock-solid stability. These kinds of sites will very likely shift to the more powerful CSS as their comfort level with it grows. Small or personal sites may want to take advantage of HTML's easy-going syntax along with CSS's powerful formatting and an occasional deprecated tag where necessary. My personal choice is to use XHTML and CSS and a bare minimum of deprecated tags. XHTML considered dangerous? There are some who question the move to XHTML. The problem stems from the fact that in order for XHTML to be backwards compatible and work in older browsers, one small concession had to be made: it had to be sent from the server in a way that browsers already understood: labeled as html. The idea was that as browsers evolved, they would eventually be able to understand XHTML pages served as xhtml. Unfortunately, that just hasn't happened. As of mid 2006, Internet Explorer 7, which will most likely assume the #1 browser mantle from IE 6 once it comes out of beta, still cannot understand XHTML files served as xhtml. That means that designers can still not take advantage of XML's strength and even worse, according to Ian Hickson, that pages written in XHTML and served as html can be more of a hindrance to the push toward standards then a help. He suggests that we should stick with HTML until browsers can serve xhtml. But then, of course, we're stuck with the snake who devours her own tail. Personally, I favor moving towards XHTML and its promise of standardization and power rather than sticking with HTML until some mythical future when browsers will lead the way toward standards. If we all write in XHTML now, it will be in the browser manufacturers' interest to support XHTML. And then we will all reap the benefits that it promises.