Tue, 2005-07-26 16:10
HTML vs. XHTML
(Third Draft) There is a certain amount of confusion around when it comes to the differences and the different reasons for using one Doctype over another.This short article will hopefully dispel some of that confusion in as plain a language as is possible, to bring a little clarity to the subject of which standard one should be writing to.
Historical
Since HTML was first created, the World Wide Web has expanded and evolved far more than was ever envisaged by its creator, Tim Berners-Lee. Website designers have pushed HTML to its limits and beyond, and even though the standard was developed and extended three times, it soon became apparent that a more flexible and robust mark-up language was called for. The new standard needed to: extend HTML's capabilities; to enable semantic mark-up instead of just presentational mark-up; to enforce more discipline in its deployment (and thus reduce the complexity of browsers currently designed to cope with bad syntax); and to enable developers to work more efficiently with the vast amounts of data that modern websites and web applications are required to handle.
Thus in 1998, the World Wide Web Consortium (W3C) combined the power of SGML with the simplicity of HTML and came up with XML (eXtensible Mark-up Language): an efficient new language with far greater power and flexibility than HTML, even though it too is derived from SGML (meaning that it is interoperable with it). The following year the W3C set about recreating HTML as an XML application, and thus in 2000 they released XHTML (eXtensible Hypertext Mark-up Language) into the wild.
In order to understand what were dealing with it is important to understand two issues:
What is XHTML
XHTML is HTML
As stated above, we mainly deal in writing web pages using a markup language called HTML, which is a subset of the older, more general, and harder to use SGML. This is a language which allows us to markup content in a human readable structure. It is not a programming language, nor a scripting one and requires a User Agent (browser) to act as the interpreter of that code for display purposes.
A far more robust and extendable language was required to cater for the ever changing nature of data and which would be able to grow and change with developments, yet which would always be backward compatible so that data conveyed by this standard would always make sense, no matter how long ago it was written. This became known as XML (eXtensible Markup Language) and it allows for other definitions to be declared. You may revise and extend the public DTD, import namespace extensions, or even create your own DTD. That's the extendable part.
XHTML therefore was a method of re-formulating the HTML syntax to be compatible with the far stricter XML syntax, whereby tags must be written in lower case letters, all empty tags must be closed, and elements nested in the correct order in the markup. In other words, the document [must be well formed.
This also allows HTML to be part of the extensible nature of XMl, and can be seen by the fact that when you declare an XHTML page you should also declare the XML namespace (<html xmlns="http://www.w3.org/1999/xhtml" lang="en">), essentially stating what language this section of the document conforms to. You can also declare further sections to be different languages using further XML namespace declarations.
It should be understood that XHTML is a bridge between HTML and XML. It is not a new 'language' but a method of integrating HTML into XML and is still HTML. Nothing has changed; you are still writing HTML markup.
Declaring your document:
It is this area that causes a lot of confusion and debate between two camps, the purists on the one hand and those that wish to follow as closely as possible the latest trends in coding on the other.
At this point to understand the debate surrounding the correct Doctype to use it helps to understand some facts:
- A modern user agent (browser) has two possible rendering engines (parsers) that are responsible for the display and rendition of your code. The first is the XML parser which is very strict on the syntax and structure of your code, and the second is what is called the 'Tag Soup' parser. The tag soup parser[1] is what is required in order that the majority of web pages on the web written before standards became a strong issue, can and will be displayed. It is forgiving of coding errors and will attempt to guess at what was intended when encountering errors or non standard code. If it were not available the majority of the web pages would cease to display.
and allows you to declare whether your document follows a 'Strict' or a 'Transitional' implementation of the standards. Therefore the dtd tells the validator which rules to apply when validating a page. You should understand that having valid html does not mean the page will render as you expect (you may have used the markup correctly, but not the right markup). Nor does invalid code mean that it won't render (the tag soup parser is designed to try and read your mind and correct errors as best as it can). Valid HTML means that you have removed the guesswork from the UA[3] Tag Soup parser, and all browsers will understand the markup. Whether they render it as you want is another issue.
The second purpose is to switch browsers between the two internal rendering modes, "Quirks Mode" and "Standards Mode" Standards mode most closely follows the W3C guidelines.
Which Doctype to code for:
According to the strict letter of the law when you code to XHTML standards the Specs state that you should serve the page up as application/xhtml+xml and that you must use the XML prolog[4] to state the character set in use. This is placed before the Doctype declaration.
This causes the first problem to be dealt with, and that is IE which will switch to 'Quirks Mode' if it sees any code/characters before the Doctype Declaration. Furthermore, IE is not capable of understanding the application xhtml+xml mime type and will process it as text/html anyway. So we have a quandary. We would like to serve up XHTML correctly but it causes us problems with the most widely used browser.
The W3C recognized this problem and pronounced on the matter that it was acceptable in light of IE switching out of standards mode, that one could serve up XHTML1.0 as text/html without the XML prolog. All well and good - we can use and validate XHTML and also ensure that IE complies with the CSS specs as much as possible.[5]
The purists argue against using XHTML for text/html documents:
Here is where the confusion arises:
There are a body of people who quite rightly will argue that to serve up XHTML as text/html is just plain wrong and shouldn't be done, and that if writing HTML the only Doctype that should be used is a HTML 4.01 strict type.
This argument is based around a number of valid points; they would argue that as soon as the mime type text/html is used, browsers can only use the tag soup parsing engine and that all benefits of XHTML are lost. Therefore you're not actually availing yourself of the eXtensible nature of XHTML, and there is little to be gained from using the XHTML Doctype. The accusation is often leveled that the current trend in using the XHTML declaration is just a fad people like to be seen as keeping up with the latest technology. There is some truth to that, and indeed many are using the Doctype without actually understanding what's involved.
The counter argument of many on this forum and elsewhere is that there are benefits to be gained by writing to the strictest disciplines that are available. In doing so we are ensuring well formed, semantically correct, valid code, and in turn,we ensure forward compatibility.
It's important to remember that well formed, semantic, valid XHTML will not only render properly in a fault tolerant html parser, but also in a strict xhtml+xml engine. Our job is to ensure the code is well written to the guidelines we have chosen.
You will also come across comments that the DTD is pretty much irrelevant as the browser does not actually process the defined document and that in reality all the doctype is good for is switching browsers between the two rendering modes Quirks and Standards. Whilst this is essentially correct it takes a rather pedantic view of things. In fact switching browsers between Standards and Quirks is an important issue and is needed.
The browser doesn't actually reference the DTD url, but the validator does. We state the document definition in order that the validator knows what set of criteria to judge our web pages against. We use the validation reports to manually correct our code, satisfying ourselves that we comply with the guidelines. It is irrelevant that the browser does not do this this is the problem of the browser not of our coding as long as we produce compliant semantic code we have done all that we can to adhere to the standards. Hopefully one day we will all be able to use XML parsers and see our code display cleanly and correctly without undue modification.
So the point of the purists is noted that HTML should only be delivered using the HTML 4.01 Doctype. There is nothing wrong in doing this. It is still a valid standard does not mean that you're not keeping up with advancements. There are many of us that prefer to work to the tightest disciplines that we can. Whilst the W3C says that it is permissable to serve XHTML as text/html then we shall do so, in reality it does no harm contrary to the now infamous article by Ian Hickson 'Sending XHTML as text/html Considered Harmful'.
To Conclude:
In all of these debates a number of issues stand out as of prime concern above all other issues. These are:
- The writing of Semantic well formed standards based markup.
- Ensuring that your document has a Valid Doctype that switches browsers into Standards mode
It is these factors more than anything that we should all focus attention on.
If these principles are followed then you are writing good code, regardless of the Doctype. The purists' arguments should not perhaps be taken as literal and the phrase "considered harmful" might be better written as "could be harmful". It is their main concern that many people sending documents as Doctype XHTML 1.0 but as MimeType text/html do not understand the issues involved in writing well formed code and that their code will break if served as application/xhtml+xml.
The contra argument could be said to be, worry not so much about the fact that you're serving XHTML as text/html but that it is well formed, semantic code, which will pass the validator's scrutiny. The benefits of working to the tighter discipline that XHTML requires, outweighs the fact that you're not directly making use of the advanced capabilities that XHTML offer. Rendering that code using the tag soup parser does not mean your code is incorrect or badly written. The tag soup parser presented with clean standards code will quietly process it without having to guess at it's intended structure. When the time comes that we can make use of pure XML parsers then our code is ready, conforming to the criteria required.
Choosing that Doctype then:
The first consideration ought to be that with new documents one should use a strict conforming DTD. There is no sane reason to use deprecated tags and attributes. Doing so will tend to produce a document that is not well formed.
The second consideration must be that you declare a Doctype to ensure that browsers are switched into Standards Mode where they will most closely conform to the http://www.w3.org/TR/CSS21/]W3C guidelines.
If you are happy that you are writing well formed, Semantic, standards based markup. then you really have a choice of two Doctypes:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
If you feel that you would like to adhere to the purists view then use HTML 4.01 it is a perfectly valid standard to write to and requires very little modification to transpose to an XHTML standard. If you wish to write to the stricter XHTML discipline then that is fine as long as you ensure that the code validates to that stricter standard, remember that if you serve up XHTML as text/html the tag soup
Parser will not tell you if your code contains errors, it will silently compensate for them. it is up to you to perform the independent validation to ensure the code is standards compliant.
Further Reading:
For those that are interested in digging deeper into this somewhat contentious area, these links are the ones to read:
Ian Hicksons original article Sending XHTML as text/html Considered Harmful
A reply to the above article by one of the contributors to the Hickson piece clarifying a number of points needing clarification
Shaneyfelt post on csscreator
Mozillas explanation of the difference between text/html and application/xhtml+xml:
http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff
The W3C on serving xhtml 1.0:
http://www.w3.org/International/articles/serving-xhtml/
Anne van Kesteren's weblog entry on how and why XHTML rendered by the tag soup engine is invalid html due to the way that tag soup engines cope with the closed empty tags such as <br />
http://annevankesteren.nl/2004/06/invalid-html
Footnotes:
[1] Prior to December of 1999, there were no really strict standards in place. HTML 2 and 3.2 had made some effort to pull things together. The browser wars mitigated against getting things right, with each vendor trying to outdo the other in features and most importantly and negatively, in fault tolerance.
In the U.S., the Campbell Soup Co. makes a product called "Alphabet Soup". It's a vegetable beef soup with bits of noodles in the shapes of letters. They're all mixed up, making no sense. From this, and the ridiculous lack of well-formedness in all HTML prior to 2000, and most since, we get the term, tag soup. We should really not be so disparaging. A more correct term would be fault tolerant HTML parser.
[2]Mime types Are the means of specifying the type of file content that is being transmitted and how it should be handled by a UA. Originally conceived as a means of expressing email content, due to it's extendable nature, other protocols make use of it such as HTTP. HTML files are tagged with the mime content-type: text/html.
[3] Consider this markup:
<table height="300">
Height is not an attribute of the table element. Will the browser try to render a 300px high table, or will it (properly) ignore the height? Now consider this HTML:
<p>This is <span>badly nested </p>html </span>
Assuming this CSS;
p {
font-size: 1em;
}
p span {
font-size: 1.5em;
}
What size will the word html
