Mark Pilgrim mentioned some examples a while ago in thought experiment. He wanted to make it clear that without ill-formed parsers syndication would be useless and it seems he's right. However, there is no browser that has other known ill-formed content handling than showing a fatal XML error. (All right, browsers have some known bugs and therefore accept some ill-formed content, but they still reject most of it.) This means that every XHTML file out there must be valid.
Fortunately, most people don't get it and use text/html so I can still use those sites. (This example may not be valid in the future. However, it does function now.)
Rakesh Pai sent me an e-mail the other day to say something about his article, The Economics of XHTML and I must say it's a great read. However, after reading Quotable: On Criticism I think you might want to do a global s/XHTML/semantic HTML/ on that article to make it read just a little better ;-)
To get back to my title, deploying XHTML on business sites is something you just shouldn't do. It can only be considered harmful.
The really bad thing about forgiving XML parsers is that their "forgiving" algorithms are not standardised.
In other words, what one parser can handle, another can't. And that's bad, because now you'll have to do a lot more testing. Isn't this defeating the object of standards?
Anyway, I still don't really see why you shouldn't deploy XHTML on business sites. Could you please give us some more reasons/resources, other than Hixie's personal views? :-)
Conclusion: XHTML will give a definite reduction in amount of space used on the server, which translates to money saved.
In comparison with HTML? Ehm… no. Clean, meaningful markup compared to presentational markup perhaps, but that has nothing to do with XHTML.
I heard a rumour, by the way, about IE6 SP2 now supporting application/xhtml+xml, under some circumstances of which I don’t have the details. Somebody clue me in?
Am I off-topic now?
I have to "painfully" admit, I'm not getting your point. To me, advocacy for valid XHTML (or web standards in general) seems to be an important and necessary job to do within the next years, so we can reach a point in time where the majority of browsers, i.e. parsers will be able to comply to these standards (and besides, (the) Firefox (community) does an awesome job for the usage of standards).
Apart from personal views (which are also very important to have sources for the building of a public opinion) I think it'll be advocacy that'll lead our way to the goal of a unified web development/application/usage environment. Don't you agree?
I don't agree that using xhtml with the mime-type text/html is bad in all cases.
Switching from html to xhtml is a very huge and difficult change for large Content Management Systems. It is impossible to test all circumstances whether pages are valid xhtml. By setting the header to text/html, every functionality keeps working until the CMS generates valid xhtml. I thinkchange should be made by evolution.
Changing the whole CMS from html to xhtml at once is not an option (that sort of revolution costs lot of time, thus money before it's completely falt-less). So I think xhmlt with header text/html is a must when a CMS switches from contentgeneration html to xhtml.
IMO XHTML is the future for content-generation, because xslt transformations brings some very elegant flexibility.
Anne, please stop reiterating your point in a different flavour. Some people get it, some don't. As usual it's a useless discussion.
The "battle" was lost when XHTML was the new hot thing, even before you were promoting it.
While it may be a lost battle, I do not agree with Mark. I think it is important to keep this discussion alive, because it seems it doesn't get enough attention! Unless Faruk can convince me with the article he promised to write, I do no longer see the benefit of XHTML for general use. As Anne and Mark Pilgrim show, using XML is disastrous in the client side, unless you can produce faultless code under all circumstances. While I'm trying to implement that on my own blog, it is darn difficult when you have to deal with sources outside of your control (comments, trackbacks, Google ads, etc).
Unless we have tools we can trust, it is much safer ro resort to good old HTML, with all the best practices of today (semantic code, seperation of content and presentation, etc). Especially when we are talking business, we should avoid XML errors, so we have to use HTML.
It might be me then, but reiterating over true words slightly annoys me. However, I'd love to see people write in their articles from now "semantic HTML or XHTML", instead of XHTML. Perhaps then people will go out and find some resources, and decide for themselves.
Since I've been making a content management system for customers that uses well-formed XHTML, I find that I can safely say XHTML is just fine to me. It introduces a lot of intricacies with Javascript, and sometimes with CSS, but it works just perfect for me, and much better than HTML ever could.
However, it'll all be explained once I write that article about XHTML and HTML. You guys'll just have to be patient for this one, for now :p
It's definitely worth reiterating, seeing as so many people still don't get it.
If everybody and their kid sister starts 'writing XHTML' and serving it as tag soup, they'll think they're doing it right, because it works in all browsers. They'll happily keep using document.write() and hiding their scripts in SGML comments, not realising that they're still serving tag soup (and bad HTML to boot).
Charl, you know it's wrong. Accept it.
Kris, I heard about that too. I think I'm going to investigate that a little more since it seems that Internet Explorer treats it as text/html. (Conclusion of my previous brief investigation.)
Christian, what is the advantage of XHTML to you? To me the only advantage is that I can use it when I'm writing in XML vocabularies, since it has some useful predefined semantics. Other than that, I don't need it and it could only hurt my business if a page gave back a fatal XML error.
The transition to semantic markup is huge and difficult. That has nothing to do with XHTML.
Mark, there are a lot of weblogs out there talking not about XHTML at the moment. You could take a break from this one and return when the web is converted ;-)
Ben++? :-)
Faruk, I really want to read you convincing reasons, since all the field experts are pointing against it at the moment.
Tommy++? :-)
Charl, you know it's wrong. Accept it.
Yes I do, but no I don't. :-)