I’m not saying it is better and I’m not commenting on the rightness or wrongness of some of the messages being associated with XHTML, I’m just pointing out that a lot of people have come to learn about web standards and CSS and tableless coding and doctypes because they first heard about XHTML. It was the catalyst for a lot of people to change their way of thinking about coding their pages.
Apologies if there was some misinterpretation of what i wrote. I meant that XHTML allows us to be more uniform in the WAY we code. For example, if i ask 5 developers to code up a 2x2 table in HTML there would be significant differences in each developer’s table code, e.g. use of quotes, height. In XHTML, the code should be almost identical (ordering of attributes allowing). Also, if i wanted to parse a page for P tags the same 5 developers may use non-well-formed tags making it impossible to distinguish separate paragraphs. In XHTML this would be simple.
Apologies for such crude examples but my point was that XHTML does help. As a team we work to the same rules and although we could have done this with HTML, using XHTML helps eradicate inconsistencies.
I think that the biggest advantage is that your document will be ready to become a full XML with just changing the way you serve it and then being able to take full advantage of what XML offers.
Nope. 
Some developers would include <tbody> and </tbody> tags, while others would omit them. Both are valid XHTML.
Really? And how do you think browsers manage? With HTML’s rules, valid markup can be parsed unambiguously. In this case, the start tag of any block-level element will implicitly close the paragraph. The next <p>, for instance. XHTML’s rules are simpler and more consistent, though. However, there is nothing that prevents you from closing paragraphs in HTML either! The fact that you may omit the end tag does in no way imply that you should.
What your organisation needs is a Style Guide that everyone has to follow. Whether you use HTML or XHTML is not relevant in this respect. If the Style Guide mandates that explicit closing tags must be used for all element types that allow them, there you go.
And here’s the clincher: even if you use XHTML markup, none of these ‘benefits’ will appear unless you serve your documents as XML. Serve them as text/html and you’ll be able to omit end tags, use unquoted attribute values, etc. Because you’re not using XHTML at all; just HTML with syntax errors. 
If you could serve the document as text/html there cannot be any XML features to take advantage of.
If you have to add those features, it will be just as much work whether you used XHTML or HTML markup to begin with (assuming that you have an editor that supports search-and-replace).
I misread it, but didn’t misunderstand it and that’s what I thought you meant in the first place; “Only ", &, <, and > will work reliably in all processing situations” though others might not have understood.
That’s why I said “will be ready to take advantage” and not “will take advantage”.
You don’t have to change the markup, just the way you serve it. Then, you could take advantage of namespaces, as an example. Am I wrong?
No, but making well-written HTML 4.01 Strict ‘ready’ in that way would be a matter of seconds, anyway.
The point is that in order to actually do take advantage of the XML-ness, you’ll have to change the markup anyway (by adding those elements from another namespace).
I use XHTML cause i like its well-formness. I like the rules like lowercase tagnames, quoted attributes, closing tags etc. Not that you can’t do this in HTML4, but the fact that this is forced for it to validate does make it easier to work with others.
Xhtml is good for validation purposes and I am surprised that there are no references to HTML Tidy. And I accept that there are layout problems with html tidy.
I like the distinction made between html and xhtml here and we should add that the browser amaya, available for download on the web site of w3c.org really belongs to this clarification between xhtml and html.
Thanks for the great FAQ and all the info you provided. It has helped me a lot to understand the difference between html and xhtml… cheers!
Personally, im a real supporter of xhtml, i use it, i write it semantically and while i could write just as tidy html4 i like how xhtml actually forces easier to read code.
Now, that aside, what the hell is the point in xhtml then? Personally, i believe we should dump html and just go for xhtml because of its better, stricter, standardised rules.
But lets face it, as always, its microsoft thats holding us back.
Tommy, thanks for great doze of info. I was pretty intrigued by the title, for for some time now I was thinking about changing the way of coding web sites and migrate to ‘modern’ way of it: xhtml (reluctantly, though).
After reading your thread it is clear to me that I don’t have to 
It’s not a modern way, it’s a different way which seems (to me) to have lots of little ‘buggers’ down the road and at the end is nothing else but regular HTML, at least with current use of it, mentioned 99.99% of ‘xhtml’ websites. Am I right or am I right?
Thanks again!
I don’t know if lots of 'em. I was not one of them for sure. When I designed and published my portfolio site, I sent a query to some forum asking people to criticize my happy designing and coding. Someone pointed out that the site is based on tables. I started learning CSS, firstly with lots of drama (seamen could not probably curse as good as I did while starting with CSS :D)
Now, all my websites are coded using tableless design (HTML 4). XHTML looks like a drama to me and, honestly, I do not want to migrate (at least not for a loooong time now)
Greetings to all members (and guests) of SP!
Greg
XHTML is easier than you think. It is just normal HTML modularized (transformed to XML using HTML tags, if you want it to put it that way).
The main problem is that, as per today, IE doesn’t support it if you serve it as an application, hence that if you want to use XML features, it is the server who needs to do the parsing. This is inconvenient because you need to have access to your server configuration.
I insist, it is not that IE doesn’t understand XML, it’s being used since IE 5.5. It is simply that IE doesn’t support XHTML served as application which is the good way to do it. 
No, it’s not normal HTML. Please read the first post in this thread. Carefully.
XHTML is XML, and is a different beast from HTML despite the superficial similarities.
I’d rather say that XHTML is more difficult than you think.
IE doesn’t support XHTML. Period. What it does support is HTML, which is what you use if you serve anything as text/html.
This is important: IE does not support XHTML served as text/html. It supports HTML with certain syntax errors in it.
I may have not expressed myself properly, my apologies, because I didn’t say that XHTML and HTML were the same thing. I said that XHTML is the modularization of HTML and transformed into XML or, if this is easier, XHTML is XML using tags that are named exactly as the HTML tags.
Sorry if the way I phrase it drives to confusion.
Well, depends on how you define support. What you say it is true. But my point of view here was simply that IE treats XHTML served as text/html as normal HTML and hence display the page as usual.
In this case, I’d define it as ‘recognise and treat appropriately’.
Yes, provided that you’ve followed Appendix C to the letter. If you expect IE to support XHTML, you’d be surprised if you tried something as trivial as this fragment of fully valid and normal XHTML:
<script type="application/javascript" src="foo.js"/>
Very possibly. Never tried that to be honest. I was sent my javascript as plain text.
molona, Tommy’s point was that IE doesn’t support terminated form for empty elements. Using a script element like that makes IE think that everything following the start tag for that element is JavaScript code.