A Beginners Guide: Do I use XHTML or HTML?

I try to be impartial, but I’m only human, so I guess you’ll have to take this as just my opinion. That being said I will do my best to provide the facts, and from that fact hopefully you can come to a decision as to what you truly want to use. This is obviously geared towards beginners as anyone with any experience is well aware of these issues. This is mainly intended for users who are completely new to website creation and who probably don’t understand the issues surrounding (x)html. Before we start I’d like to point out this article written by Loren Wolsiffer that you’ll probably want to read after this. (It’s not written very well and you may not understand a lot of what he’s talking about until after you read this)

Value of XHTML

Benefits of XHTML

  1. XHTML must be valid code.
  2. XHTML must be well formed xml.
  3. XHTML throws catastrophic errors when it encounters invalid code.
  4. XHTML can use alternate xml namespaces.
  5. XHTML makes DOM scripting easier.
  6. XHTML can have xml tools used on it for content management.

Downsides of XHTML

  1. XHTML doesn’t work in IE AT ALL if served as xhtml.
  2. XHTML doesn’t display until fully downloaded in mozilla browsers.
  3. XHTML confers no practical value if served as text/html.
  4. XHTML doesn’t allow document.write() javascript. (Which is viewed in a positive light by some)
  5. Inline scripting and CSS are broken unless you use extremely long escape sequences (not an issue as you should have that all modularized anyways). Inline scripts/css are stored in the html document rather then a .css or .js file.

More markup issues

Value of HTML

Benefits of HTML

  1. HTML 5 is in development by WHATWG . (no longer a dead language)

Downsides of HTML

  1. None.

Facts on XHTML and HTML

Fact 1 – XHTML is properly served as application/html + xml.

application/html + xml is a mime type the web server passes the browser in the http header. A mime type simply describes to the browser what type of file it’s getting so it can decide what to do with that file. It is nothing you can control inside the document itself. If passed application/html + xml, you don’t even need to state a DOCTYPE as the browser automatically assumes XHTML 1.0 strict. That being said, if you don’t have access to the web server(or server side script), you cannot change the content type. If the server can’t serve application/html + xml, you can’t get any of the “practical” benefits from XHTML.

As an aside: The one other practical benefit of XHTML is the use of xml tools with the document such as a Content Management System.

Fact 2 – XHTML is only “practically” beneficial when served as application/html + xml.

Yes I agree that XHTML is theoretically beneficial to practicing good coding techniques, but I disagree that html is not also helpful in that regard. Many argue that XHTML forces proper coding techniques such as lowercase element names, enclosing values in apostrophes, and using proper closing tags. However, you can still do that in html 4.01, even though you don’t have to.

It’s also argued that XHTML is theoretically beneficial in “future-proofing” their document. But that theory is also flawed as now both XHTML and HTML 5 are in development.

The only way to get the proper xml rendering and error checking for XHTML is to serve it as application/html + xml. Without declaring that mime type, what you are serving is invalid HTML 4.01.

Fact 3 – XHTML served as text/html is invalid HTML 4.01

“Current UAs (Browsers) are HTML user agents (at best) and certainly not XHTML user agents (certainly not when sent as text/html), so if you send them XHTML you are sending them content in a language which is not native to them, and relying on their error handling.” – Ian Hickson

XHTML is designed to be served with the mime type application/html + xml, and when not, is passed as text/html. The browser can make it work due to an SGML parsing bug. So I guess if it works more power to you but it doesn’t make it proper. So, yes an XHTML document may be well formed, and yes it may validate, but the browser thinks it’s html, forcing the browser to guess at what you mean.

Fact 4 – XHTML served with application/html + xml content type is unsupported in ie7 and older.

This is the killer for me, I would be using XHTML right now on my personal sites right now if it weren’t for this. Quite possibly on my commercial sites as well, but we use third party software on some of them which would make conversion and upkeep a pain.

When you send XHTML with the content header of application/html + xml, IE renders an xml tree. Not only that, but IE7 doesn’t support the application/xhtml + xml mime type. As of this writing it does not appear that IE8 will have xhtml support. At this time I’m not certain I’d get my hopes up that IE will ever support xhtml. With no IE support you can’t reliably use XHTML unless you don’t care about serving to IE users.

Fact 5 – HTML is always supported.

HTML is going to be around for a good while longer, a lot longer then any of us had probably anticipated 5 years ago. It’s supported in all mobile devices, and it’s unlikely the devices will ever leave the SGML parser and go to a strictly XML one. In addition the WHAT WG is in development of (X)HTML 5.

Fact 6 – <?xml version=”1.0″ encoding=”UTF-8″?> Triggers quirks mode in IE6.

You don’t want quirks mode, ever. XHTML is meant to be strict, and if you’re triggering quirks mode you’re implenting counterproductive practices. Quirks mode was designed so browsers could handle documents that haven’t been accurately described with a doctype. Many elements are displayed differently in quirks then in standard mode and you will create some issues with css.

What does all this Mean?

Choose the option that works for your project.

Ultimately choosing a doctype is personal preference, as you’re going to create in whatever environment you’re comfortable in. This article is intended to instruct that you shouldn’t just copy an XHTML doctype (or any doctype for that matter), or add an XHTML doctype without understanding the implications.

What should you choose?

It’s all dependent on the project, and that’s what should matter most. For most beginners HTML 4.01 will probably suffice for anything you’d need to do, and when it validates you’ll know that in _most_ environments it’ll render correctly.

If you want to use MathML or SVG and don’t care about IE users then by all means use XHTML served as application/html + xml.

If you enjoy learning to conform to the strict coding practices of XHTML and serve as text/html, then by all means go ahead, but keep in mind that if you ever try to serve it later as application/html + xml that it probably break HORRIBLY.

What would I choose?

Bias? 🙂

I would choose HTML 4.01 for anything not requiring MathML, SVG or XML content tools. I know HTML and I write it as close to XHTML as possible. In my opinion the negatives of XHTML far outweigh the benefits. Sure I loathe MS as much as the next person, but I’m not going to abandon what could possibly be 80% of my users. I also would be afraid to use proper XHTML in the workplace as I probably won’t be employed there for ever, and when someone else could start adding content to the site it wouldn’t take much to completely break the site.

Be Sociable, Share!
This entry was posted in coding. Bookmark the permalink.

Comments are closed.