XHTML vs HTML FAQ

[AutisticCuckoo]

When you say XHTML served as application/xhtml+xml doesn't work in IE, what do you mean by that?

I mean that IE does not recognise that MIME type and will prompt the user for what to do with the document.

Maybe my memory is wrong, certainly I rarely serve up pages as application/xhtml+xml myself, but I seem to recall that a few years back that IE would display pages like that as an XML tree.

That's what happens if you serve your document as application/xml or text/xml (and don't use a style sheet).

But, the last time I checked this, I thought IE was displaying those pages just fine.

In that case, my guess is that you've added appliction/xhtml+xm as a recognised MIME type in your Windows registry.

This set of three pages (links at bottom of the pages) are being served as application/xhtml+xml:
...
Both work fine in IE Windows here.

They are indeed served as application/xhtml+xml (at least to Opera). I can't check in IE right now (I'm on Linux). You're not using content negotiation to serve it as text/html to non-XHTML browsers?

[cperkinsatmedialab]

You're not using content negotiation to serve it as text/html to non-XHTML browsers?

No, none.

I've never modified the Registry myself to add that MIME type, didn't even know that was possible until I read your article.

Maybe some other posters can look at that xhtml link in IE and let us know what they see. Certainly, Microsoft has had at least one dramatic update to IE recently (eolas), and they've had many other opportunities to update it with their monthly updates. Perhaps they snuck in a bug fix during this past year.

Chris

[Viflux]

For the record, IE prompts me to d/l those pages.

[disgracian]

Can I set the MIME type with a <meta/> tag?
No. A user agent needs to know the content type before it starts parsing the response body. When it encounters an element like this, it's already too late:

<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8"/>

The MIME type must be sent as a Content-Type HTTP header. The character encoding should be specified in the XML declaration (see above).

What does that meta tag do then, and why is it used if the HTTP header sets the MIME type?

Cheers,
D.

[AutisticCuckoo]

A <meta> tag with an http-equiv attribute is used for specifying equivalents for HTTP headers. Those equivalents are only used if the corresponding HTTP headers are not sent by the web server.

As for Content-Type, you cannot change the content type once parsing has commenced, but it may have an effect on the character encoding if the optional charset attribute is present. Thus this tag is usually used for specifying the character encoding of HTML documents that are read from the hard drive, rather than being retrieved via HTTP.

This specific header is pointless for real XHTML documents, but it may be useful for setting the character encoding in 'XHTML' documents served as text/html since they are treated as HTML documents anyway.

[disgracian]

So what you're saying is that if the server sets the Content-Type (my ISP's webspace specifies both the MIME type and character set) then there's really no point in having this line in your documents?

I originally used <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />, but the W3C validator reported a character type mismatch because the server was apparently specifying ISO-8859-1.

Cheers,
D.

[AutisticCuckoo]

So what you're saying is that if the server sets the Content-Type (my ISP's webspace specifies both the MIME type and character set) then there's really no point in having this line in your documents?

There is: if I were to save your web page on my hard drive in order to read it off-line (not inconceivable for dial-up users), there would be no web server to send HTTP headers. Thus the <meta> element would be useful.

This applies for HTML documents (including XHTML markup served as text/html).

Real XHTML documents should use the XML declaration to specify the encoding, and should be saved with a .xhtml file extension. That way they will work properly (as XHTML) even when viewed off-line.

[disgracian]

That seems so obvious in hindsight. Thanks again.

Cheers,
D.

[itpastorn]

The FAQ should mention that XHTML does not support the target attribute.

This actually has nothing to do with XHTML per se. It's about the Doctype. HTML 4.01 strict does not allow the target attribute either.

It is a common misconception to think some issue shows the difference is between HTML and XHTML when it's really about strict vz. transitional or frameset doctype.

Lars Gunther

[examhome]

so useful,Thanks

[ricoche]

I'm a bit confused about how the new .mobi domain and serving mobile content fits into this. Isn't it possible that Xhtml and Xhtml Mobile might become more popular with the advent of increasing mobile oriented websites? If so, I would think that Xhtml would become very important.

If you have a domain.mobi website and it gets added to google or some other search engine, I feel it's quite possible that people using IE6 or IE7 are going to click and check the site even without a mobile phone. If that's the case, then they'll get prompted with a download instead of viewing the site. I notice that Google Mobile for example allows you to view their site via any browser and a mobile device. Are they using some other content than Xhtml? I noticed via source that they have an Xhtml Mobile header in there if correct.

I never even touched hardly Xhtml before I acquired a few .mobi domains and started researching how to build sites. There's .wml of course, but it seems most of the limited info out there pertains to building mobile sites with Xhtml. Thus if .mobi takes off, then IE for example might need to get with the program and start making their browsers compatible. Not sure.

I would love to see more info about this on Sitepoint as I'm sure more and more people are going to wonder about Xhtml and why it's related so much to building mobile websites.

Perhaps I am misunderstanding something as I am still pretty new to this. I just know that if I use HTML, my .mobi sites break and if I use Xhtml/Hhtml Mobile they work great.

Since Google is backing .mobi domains and websites, I'm curious about what technology they use to build their sites and whether we should follow suit. I can't tell if they are using Xhtml, Php, Asp, etc when viewing the source of their mobile site. Actually I see in their URL it's http://www.google.com/xhtml . If I type google.mobi then it gets redirected to http://www.google.com/mobile/ . Interesting.

Thanks for any clarification or additional insight into this interesting topic I think about Xhtml.

Jim

[xhtmlcoder]

I assume it is how you have configured the server itself.

As Google it uses Proxy Servers and for Google /xhtml/ Mobile Web (Beta) it lists my website which is in XHTML Basic 1.0.

[AutisticCuckoo]

You basically have two options if you're determined to use XHTML syntax in your markup:

1. Use XML features, serve as application/xhtml+xml, lose IE users.
2. Use no XML features, serve as text/html, rely on UA error handling.

The former is probably not a commercially viable option for mainstream sites. The latter cannot offer any advantages over HTML, since it is HTML (although badly written).

In theory, XHTML would be great for mobile devices. An XML parser is more lightweight than an HTML parser and should be a bit faster. In practice, it's a different story. A mobile device with an XHTML-only browser wouldn't be able to access more than a tiny fraction of the web: those few pages that comprise well-formed XHTML served as XML.

That's probably very similar to what surfing the web was when I first started doing it in 1993 or so. There were not many sites available, and most of them were quite boring. The greatest moment of the day could be accessing an Australian vending machine connected to the Internet, to see how many cans of Coca-Cola were left in it.

Given time, it's possible that XHTML will get out of the Appendix&#160;C quagmire in which it is currently bogged down. Just like the web flourished, XHTML may also do so in a few years. Personally, I don't think it's going to happen with XHTML&#160;1, though. It's dead, because it has been abused too much by people who didn't recognise it for what it was, but thought it was some new, cool version of HTML. Maybe XHTML&#160;2 will change things, since it's not going to be backward compatible with HTML (or XHTML&#160;1), but it's anybody's guess when it will become a full W3C recommendation, let alone when user agent support reaches critical mass.

[cperkinsatmedialab]

Desktop and mobile browsers aren't the only consumers of web pages, there are also a very large number of tools that have to read or write web pages. As a programmer myself, I far prefer to write code to parse or generate XHTML with it's good XML based structure than HTML with its long list of exceptions.

One of the web apps I'm working on uses XHTML as the preferred input, for which we guarantee correct results. If the user provides HTML, then they get what they get, which may often not what they expect.

Chris

[zcorpan]

Desktop and mobile browsers aren't the only consumers of web pages, there are also a very large number of tools that have to read or write web pages. As a programmer myself, I far prefer to write code to parse or generate XHTML with it's good XML based structure than HTML with its long list of exceptions.

One of the web apps I'm working on uses XHTML as the preferred input, for which we guarantee correct results. If the user provides HTML, then they get what they get, which may often not what they expect.

You can just run the input though TagSoup or so and then carry on as if the input was XHTML.

[kaydie]

AutisticCuckoo:

From the WHATWG site:

We need to explain the difference between XHTML and HTML somewhere, probably earlier in the introduction in fact, but the problem is I don't know how to explain it. If someone can come up with some good text to describe the difference and similarities between the two (namely that they are just different serialisations of the same in-memory structure, with a few caveats), then please send it to the WHATWG list so I can include it. The problem is making it accurate while keeping it simple enough that people who don't know what a serialisation of an in-memory structure is can still get it. (The relevant section doesn't have to be normative, if that helps.) The sentence "Every XML and HTML document in an HTML UA is represented by a Document object." from section 2.3 should seem perfectly reasonable after someone has read this section.

http://whatwg.org/specs/web-apps/current-work/#html-vs

hint, hint…

[AutisticCuckoo]

[Mitlik]

One of the things that this doesn't seem to touch on, after skimming it quickly, is if using XHTML to have access to some of its options, in my case MathML, does it need to be served as application/xhtml+xml or will the MathML still work if served as text/html?

[AutisticCuckoo]

As stated in the FAQ, you will only benefit from the XML part of XHTML if you serve the document as XML, i.e., as application/xhtml+xml, application/xml or text/xml.

If you serve it as text/html, it is HTML. HTML does not support XML namespaces (since it's not XML), so you cannot use MathML, SVG, or other XML namespaces with HTML.

[Rick]

Congratulations to AutisticCuckoo, who (as the starter of this thread) has won the Most Helpful Thread of the Year 2006 award

[xhtmlcoder]

He's just the White-headed Capuchin; but like I told him, that one would get the many votes, well done Mr T.

[joejoe04]

To start, absolutely great thread, and the award was completely deserved. That said, I can't help but bring up the fact that sitepoint is currently using XHTML. I came into learning (X)HTML and CSS right in the middle of what was previously discussed as "everyone getting excited about using XHTML just to use it and not because of its benefits." Because of this, I really prefer the syntax of XHTML b/c that's just what I have always been using I guess. So my question would have to be then, so long as I don't add anything outside the range of what HTML can do and make sure to validate my code, am I ok to just continue on using the XHTML syntax? This seems to me what Sitepoint is doing...or am I wrong about something. Thanks.

[AutisticCuckoo]

SitePoint is using forum software (vBulletin) and it's likely that it's not worth the trouble converting templates and scripts to make them generate HTML instead of XHTML. One definite advantage of XML markup is that its syntactic rules are much more consistent than those of HTML. That makes it easier to generate, as well as to parse.

If you follow all the guidelines in Appendix C of the XHTML 1.0 specification and make sure that your pages still work as intended when served as, e.g., application/xhtml+xml, there is no real harm in serving XHTML markup as text/html.

Validation is one thing, but you can write valid XHTML markup that will not work when served as an application of XML. That's why you need to verify this (as outlined in the FAQ). A document with XHTML markup that only works when served as text/html is a very bad and dangerous thing, in my opinion. That's when I agree with Ian Hickson: it's harmful.

[joejoe04]

Validation is one thing, but you can write valid XHTML markup that will not work when served as an application of XML. That's why you need to verify this (as outlined in the FAQ). A document with XHTML markup that only works when served as text/html is a very bad and dangerous thing, in my opinion. That's when I agree with Ian Hickson: it's harmful.

I can definitely see how it can be harmful. Just one more point or I guess question though. The future benefits that use of XHTML or XML offers seem to me to be pretty substantial as discussed throughout this thread. My question I guess is, If we are convincing everyone to go back to HTML, do you think this slows down the progression towards XHTML?

[AutisticCuckoo]

The main factor that is slowing down the progression towards XHTML is, in my opinion, Microsoft. As long as IE – which is what a vast majority of people are using, whether we like it or not – doesn't support XHTML in any way, shape or form, real XHTML will continue to be a niche product.

I wrote about the misconceptions surrounding XHTML several times on my now dormant blog. One of the things I tried to point out is that we don't have to go to extremes. If we choose to use HTML for the time being, it doesn't mean we have to write it like we used to do in 1995.

You can write HTML 4.01 Strict in a way that is almost indistinguishable from XHTML 1.0 Strict (as used by 99.999&#37; of contemporary sites). Converting this sort of HTML into XHTML can be done very easily (change the doctype declaration, add a namespace declaration and add NET separators to empty elements).

Remember, XHTML 2.0 or 3.0 or whatever it will be when it becomes properly supported is unlikely to be backwards compatible with HTML or XHTML 1.0. That means that even our current, carefully crafted XHTML markup will be out of date. The 'future proof' argument is probably quite exaggerated.

So, to finally answer your question: no, I don't think using HTML 4.01 Strict today will slow the progression towards XHTML whenever it becomes usable. Changing such an HTML document to XHTML 2.0 will involve no more work than changing an XHTML 1.0 document to XHTML 2.0.

A much more important aspect of future-proofing is the separation of structure, presentation and behaviour. Use external CSS for presentation and external unobtrusive JavaScript for behaviour, and leave only the document structure and the semantics in your HTML or XHTML. This is what will facilitate the progression towards future markup languages, if the current trend is anything to go by.