Quote Originally Posted by fluffyland View Post
My point is that *I* find it more convenient having my data in xhtml
I agree, and I haven't heard anyone that disagrees that X(HT)ML is very useful as a data storage format. The question is whether it is suitable as a final delivery format for presentation to end users.

Quote Originally Posted by fluffyland View Post
There are people responding to this forum saying that now they're not going to put their material up as xml because some people are telling them that they *have* to serve it as application/xhtml+xml and that won't work in IE.
No, what we are trying to say is that you must make sure that your XHTML document (plus related CSS and JavaScript) works when served as application/xhtml+xml to a compliant user agent.

If you want to use XHTML markup but serve it as HTML, you're free to do so. It's quite acceptable, as long as it also works when served as an application of XML. If it must be served as HTML, then you are doing the wrong thing, and you cannot claim that there are any advantages to using XHTML (because you're not).

Quote Originally Posted by fluffyland View Post
It all seems to have stemmed from Ian Hicksons blog and I don't agree with his arguments. (and yet people who like xhtml are told they've just "jumped on a bandwagon")
Then provide objective, verifiable evidence to the contrary. If you say he's wrong, then show the world the truth.

Quote Originally Posted by fluffyland View Post
1. Things go wrong if you don't do it properly - then do it right.
The problem is that you may not be aware that you don't do it properly, because the problems don't show up as long as you serve the document as HTML. Validation doesn't catch all problems, either. If everyone knew what they were doing, we wouldn't be having this discussion. Unfortunately, a majority of those who create 'XHTML' documents seem to believe that XHTML is a newer version of HTML.

Quote Originally Posted by fluffyland View Post
2. There are some things you can do that are valid xhtml that break browsers - then don't do them.
In other words, don't use anything that isn't available in HTML. Then you can just as well use HTML in the first place, right?

Quote Originally Posted by fluffyland View Post
5. Some mythical fully compliant SGML parsing web client is justified in scattering ">"s all over you page - I don't think I've ever seen one and you'd be pretty stupid to build one now.
I personally don't feel comfortable with relying on bugs, but that's me. And that last sentence is exactly what Hixie was talking about: because of the proliferation of pretend-XHTML, it is no longer viable to build a parser that handles HTML correctly. I think it would be rather nice to be able to write <abbr/HTML/ and <>CSS</> instead of the more bloated <abbr>HTML</abbr> and <abbr>CSS</abbr>, but that will never happen now.

Quote Originally Posted by fluffyland View Post
I'm not even sure there was a fully compliant SGML parser because the standard was so bad, that's *why* they created XML.
It's not because SGML is bad, but a full SGML parser is quite complex. SGML is a language for defining markup languages. Browsers don't need SGML parsers, but it would have been nice if they at least supported HTML.

XML is a subset of SGML with lots of restrictions which, in conjunction with the requirement for draconian error handling, makes it fairly trivial to write an XML parser. (Internal subsets are the only things that really complicate matters.)