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
(see page 25)
. 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 extensionssince they leave out part of your audiencethere 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.
|
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, in
http://hixie.ch/
advocacy
/xhtml
, 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.
|
|