There are certainly
a lot of differences between XHTML and HTML.
First of all, HTML is based on SGML whereas XHTML is based on XML. The X is short or extensible, i.e. Extensible Hypertext Markup Language.
Unless XHTML is served as application/xhtml+xml then it won't (and should not) be treated as XML by the UAs. If it's served as text/html then it will be treated as HTML. Some people think that it is the DTD that determines whether it is XHTML or HTML, but that is wrong. The DTD is merely a document containing grammar constraints. Of course if you serve XHTML as text/html then you miss out on the "extensible" part of XHTML, but if you serve it as application/xhtml+xml then you won't have any IE users for sure.
XHTML, when served as such, can be extended by any other XML based technology using XML namespaces. An example of that could be MathML. Inserting the following in an XHTML document:
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<mi>y</mi>
<mo>=</mo>
<mfrac>
<mn>1</mn>
<msqrt>
<mrow>
<msup>
<mi>x</mi>
<mn>2</mn>
</msup>
<mo>+</mo>
<mn>1</mn>
</mrow>
</msqrt>
</mfrac>
</mrow>
</math>Would produce something like [tex]y=\frac{1}{\sqrt{x^2}+1}[/tex] when served as application/xhtml+xml, but if you serve it as text/html then it'll look like
y = 1 x 2 + 1 because all those elements are invalid in HTML and as such ignored. Another example is SVG for embedding vector graphics.
Here is another difference:
HTML-style<style type="text/css">
<!--
h1 {
font-size: 1em;
}
</style>XHTML-style<style type="text/css">
<![CDATA[
h1 {
font-size: 1em;
}
]]>
</code>If the former snippet is (wrongly) served as application/xhtml+xml then it won't work, and similarly, if the latter snippet is (wrongly) served as text/html then it will not work either.
Furthermore, the default character set for HTML is latin-1 (ISO-8859-1), but the default character set for XHTML is UTF-8. Indeed the only character sets an XML parser is required to support is UTF-8 and UTF-16. This can result in an odd output littered with strange symbols if you do it wrongly.
The thing is, you
cannot use XHTML for Internet Explorer. It simply does not support it (the user will be prompted to download the page because IE doesn't know what to do with it). Some people have proposed to use content negotiation to serve different content to different UAs, but the problem is that a lot of the UAs lie about what they do accept. You will for instance find
*/* in IE's
Accept header, but this is quite obviously untrue. That would constitute supporting literally every thinkable MIME type, including those which have not yet been invented. This would mean that it claims to support application/xhtml+xml as well, but it is fairly easy to verify that it does in fact not.
Moreover, the working draft of XHTML 2 is not backwards compatible with XHTML 1.x or HTML 4.x. HTML 5 will be backwards compatible. It doesn't look like XHTML 2 is going very strong whereas HTML 5 is well on its way.
There are a number of subtle syntactical differences between XHTML and HTML. Most notably the XML self closing tag. HTML does not support this. If you have
<img src="foo.jpg" /> in HTML (or indeed XHTML served as text/html which then
de jure is HTML) then it will technically speaking be invalid. The
/ is regarded as an invalid attribute and discarded. So a lot of those websites featuring "Valid XHTML 1.0" should say "Invalid HTML 4.01".
All of those are just some of the differences between XHTML and XML.
In 2007, Håkon Wium Lie (CTO of Opera and W3C member) said "So, I don't think XHTML is a realistic option for the masses. HTML5 is it." (
source). Microsoft has also expressed that XHTML will not be supported in IE in the near future. Numerous other notable people in the industry have also stated that HTML is the way to go.
Well...it does look a lot neater when you've closed all tags in the right order..idk, i just prefer it...
There is no reason why you cannot do that in HTML as well.
By the way, I'm going to sticky this topic.
