Right on time for the new millennia, at the 26th of January 2000 ((“No one likes a math geek, Scully
” – Mulder)), the W3C released a new version of HTML: XHMTL 1.0.
This happened exactly one month after releasing (right on time for the old millennia) HTML 4.01 (on the 24th of December 1999), the last version of HTML that would be based (directly) on SGML. And also the last one that is explicitly supposed to be delivered as text/html
.
Since that 26th of January a lot – if not most – web developers have switched (and with them, many of the pages on the inter web) to the new XML-Syntax of XHTML. But almost no one has switched to the new – and probably better – MIME-Type of application/xml+xhtml
, instead it’s delivered as text/html
as HTML is supposed to be served ((Mind you, this perfectly valid with XHTML 1.0)). Why is that? Why is the web stuck between HTML (SGML) and XHTML (XML) and between the centuries?
It’s fear ((what will keep the local systems in line…)).
It’s fear of this battle stationthe Yellow Screen of Death.
Since XHTML (with the XML mime type) is parsed like XML, it is subjected to the XML error handling. And that means if your document is not well formed the parser will abort it’s work and exit with an error message. Or in other words: your page will crash and burn bright whiteyellow like that certain Death Star.
This behaviour has been the main reason for XHTML as XML being rejected and has triggered a great amount of controversy amongst web professionals. Let me assure you that this is not supposed to be another post in the never ending HTML-vs-XHTML-Flamewar-Of-Death. Instead I’d like to talk about different implementations of the Yellow Screen in different browsers – and my experiences with that.
Examples of different error handling
I have created an example of an invalid XML document. Be aware that this will trigger the yellow Screen of Death! Use your “Back” button to return to this page.
This is what you’ll be getting in different browsers:
Gecko (Firefox, Netscape, K-Meleon etc.)
Mozilla is trying to scare us to death with its furious (and classy) Yellow Screen of Death. Annoying yet beautiful.
Webkit (Safari, Chrome)
Webkit renders the document up to the error, and will go that far and no further. At least part of the information is accessible.
Opera
Opera makes us feel much less like dying when faced with their version of the Death-Screen. Its also the only rendering engine that gives us an escape route and offers to reparse as HTML. That’s actually quite reasonable, since XHTML is parsable as HTML and almost all the content will be recovered to the user.
Konqueror
Konqueror accepts xhtml and just parses it as HTML, hence there is no Screen Of Death. Pity!
Dillo
Dillo doesn’t seem to parse XHTML at all, so there is just a Blank Screen Of Death.
Internet Explorer
Explorer prefers to die every time it encounters an XHTML document (with proper MIME-Type), even if it is well formed – it offers to download the document!
This is especially frustrating since Explorer has actually been able to handle XML quite well for a long time!
There is a workaround (by Dean Edwards) however (apart from just feeding HTML to Explorer) which feeds Internet Explorer XHTML as pure XML and uses a XSLT-Stylesheet to prevent it from rendering a DOM-Tree.
Let me reiterate this: Explorer is fully capable of XHTML, it just doesn’t want to!
I’ve created a test case (Be aware that this will trigger the Yellow Screen Of Death as well!) using Dean Edwards technique.
This Trick gives us the chance to explore the Explorer Screen Of Death, here it is:
(Identical in IE5.5, IE6, IE7 and IE8.
Not much to look at, huh. O well, at least it’s there. Could have been yellow, though.
Whats missing
As far as I can see only iCab is missing from this list. I will test it as soon as I get my hands on it.
Serving a Site as application/xml+xhtml
As I have said I have my fair share of websites being delivered as application/xml+xhtml
: I have two sites currently running and even ran a commercial project as real XHTML – and have yet to experience any real downtime. I wouldn’t recommend it though. If someone tries to edit something and doesn’t get it right, or messes up your character encoding – boof, your site is gone. And then people will come and yell at you. Which is bad. Also, your clients won’t be pleased once this happens:
Our site is down again! Your company sucks!
or, in other words:
If you get it right, no one will notice. If you get it wrong, no one will forgive you.
But, in fairness, there are upsides. To me, valid markup on my personal sites is imperative,
so by using application/xml+xhtml
I can ensure that I notice when my mark up breaks ((which led me to disable wordpress’ visual editor)). Also, this strict error handling can assure (well, force) your projects will stay well formed when you hand it to someone else. Note that this will not keep people from messing up your mark up, it’ll only ensure well formedness. This however might not be a good idea, since people are going to yell at you anyway.
Read more elsewhere…
As said, there is and has been a lot of discussion about whether or not using application/xml+xhtml
, so I’m not going to reiterate these arguments, but you can read further on (read the discussions below the articles!) at
When did people stop caring about application/xhtml+xml?
by Robert Nyman- Arguments about whether to use XHTML or HTML for the new Habari Project
- The almost epic, but not undisputed, article “Sending XHTML as text/html Considered Harmful” by Ian Hickson
By the way: many of the screenshots have been made using the great browsershots.org-service.
Update: You can download all the Screenshots made by browsershots.org