XHTML vs HTML FAQ

[AutisticCuckoo]

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.

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).

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.

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.

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?

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.

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.)

[Ratman2050]

Nice FAQ thanks!

[Enoch Root]

Tommy, if you're around, we had a chat quite a while ago about this issue, but I remembered also reading that XHTML 1.1 should be avoided. What are the reasons for avoiding XHTML1.1 if they are different from the reasons for avoiding XHTML generally?

[AutisticCuckoo]

The main reason is that XHTML 1.1 isn't 100&#37; backwards compatible with HTML, so it mustn't be served as text/html. If you can serve it as an application of XML it's okay, but that excludes all public-facing sites.

XHTML 1.1 doesn't really offer anything over XHTML 1.0 Strict, unless you need Ruby annotations. Those aren't natively supported by any browser (AFAIK), so your visitors will need the appropriate plug-ins for it to be useful.

[Enoch Root]

Thanks Tommy, maybe I should ask the CMS vendor why they are using it. It's for public facing sites so makes little sense.

[Enoch Root]

Can I just ask if I've understood all this correctly?

• One probably ought to use HTML 4.01 Strict.
• One may use XHTML 1.0 served as text/html if one follows the backward compatibility guidelines and validates.
• One should not use XHTML 1.1 unless served as application/xhtml+xml

if one uses XHTML and someday it starts being served as application/xhtml+xml, your site will break unless you have been super-careful.

If this is the case, doesn't it depend a bit on the "someday" - if it's never served as application/xhtml+xml, it's not going to be a problem is it? I know you could argue if it's never going to be served as appplication/xhtml+xml, what's the point of using XHTML anyway...I just want to be sure I've understood the implications.

[AutisticCuckoo]

• One probably ought to use HTML 4.01 Strict.
• One may use XHTML 1.0 served as text/html if one follows the backward compatibility guidelines and validates.
• One should not use XHTML 1.1 unless served as application/xhtml+xml

That's more or less correct. For the second bullet point, I'd add, 'and make sure it works when served as application/xhtml+xml'. There's no need to use XHTML 1.1 at all, unless you need Ruby annotations.

if one uses XHTML and someday it starts being served as application/xhtml+xml, your site will break unless you have been super-careful.

You should always test the document as real XHTML, even if you then serve it as text/html. With a server-side language that's easy to achieve. On a local hard drive you can do it by renaming the file to end with .xhtml or .xml and open it in Opera, Firefox, Safari, etc. (Not IE, of course.)

If this is the case, doesn't it depend a bit on the "someday" - if it's never served as application/xhtml+xml, it's not going to be a problem is it? I know you could argue if it's never going to be served as appplication/xhtml+xml, what's the point of using XHTML anyway...I just want to be sure I've understood the implications.

You've pre-empted my reply. If you have no intention of ever using XHTML, then why write XHTML markup to begin with?

But the answer to your question is that it won't break. It will just keep being invalid HTML until the world ends. Because pretend-XHTML has been used to such a large extent, it is now impossible to make a browser with a compliant HTML parser. Millions and millions of pages would break.

That means we'll never get to enjoy the SHORTTAG features of HTML.

[Enoch Root]

Does this mean that the use of XHTML as advocated by the likes of Zeldman et al was a complete waste of time? Why are so many people pushing for XHTML use if it was ultimately pointless? Why is my CMS vendor using XHTML 1.1 for crissakes? How deep is the ocean? How high is the sky?

All questions I expect you've been asked a million times. Except maybe for the sky bit.

[AutisticCuckoo]

Does this mean that the use of XHTML as advocated by the likes of Zeldman et al was a complete waste of time?

Zeldman mainly advocated the use of web standards, semantic markup and a separation between content and presentation. XHTML happened to be the buzzword of the day at the time, so unfortunately it became closely associated with those other things by people who couldn't be bothered to learn the whole truth.

Why are so many people pushing for XHTML use if it was ultimately pointless?

Because they have been duped into believing that XHTML is better, faster, more semantic, future-proof and will improve your chances with the opposite sex.

I've recently had a long, fruitless discussion about this topic on Robert Nyman's blog: When did people stop caring about application/xhtml+xml?.

The first version of HTML was similar to how word processors work(ed). The tags were just on/off switches for things like italic or bold text. From HTML 2.0, it became an application of SGML. SGML (Standard Generalized Markup Language, ISO 8879) was conceived in the 1980s, when the world of technology was much different from what it is today. Omitting anything that wasn't strictly necessary (like certain end tags) seemed like a good idea back when 14.4kbps modems where the bee's knees.

The problem with SGML is that a compliant SMGL parser is a fairly complex piece of software. Even if you write a specialised parser for HTML, it's still not trivial if you want to be fully compliant (which no browser is).

When XML came along, people had realised that a few extra bytes here and there wasn't such a big deal. Consistent markup rules were more important, because it meant you could write much smaller and simpler parsers. Draconian error handling is the price you pay for that (although I know Anne disagrees).

Using XML – in the shape of XHTML – for web pages would facilitate aggregation of content from various sources; the popular mashups that are sometimes said to be part of the ethereal Web 2.0 concept.

But it's the nature of the web that anyone can publish whatever they want. You shouldn't have to be a rocket scientist to put up a one-page site for your family and relatives, or a teen pop star fan page. Draconian error handling (which is mandated by XML) is not conducive to simple publishing. In other words, XML is not suited for web pages.

Thus we have two choices:

1. Use HTML, which is well-supported and forgiving, but harder to re-use.
2. Use real XHTML, which is easily parsable but unforgiving in extremis (and not supported by IE).

There are pros and cons of both alternatives. Then someone came up with the seemingly brilliant idea of using XML syntax but serving it as HTML. By a stroke of luck, virtually all browsers had buggy parsers that let us get away with that without sprinkling forward slashes all over the page.

It looks appealing on the surface and, as with so much else, most people can't be bothered to go beyond that. If MIME types make your life more complicated, then ignore them! If document.write() doesn't work with application/xhtml+xml, then serve as text/html – end of problem!

Sadly, many authors still believe that they are really using XHTML. They won't listen when we tell them they're not. How could that be – the W3C validator says it's valid XHTML 1.0 Transitional! That's much more semantic and future-proof than that dusty old HTML 4.01 Strict, right?

All right, I'll go take my medicine now.

[Enoch Root]

So, the "fast track rendering" that Zeldman says browsers give to XHTML - that only applies to XHTML served as application/xhtml+xml, is that right?

Zeldman does seem to be aware of the issue of MIME types, as he says that

"it is properly served with a MIME type that causes some popular current browsers to misbehave".

But presumably a lot of his "top ten reasons" to convert to XHTML actually apply only to XHTML served as application/xhtml+xml?

He also mentions top 5 reasons not to switch to XHTML - one of which is

"You enjoy creating multiple versions of every page for every conceivable browser or device"

Is this a fact?

[AutisticCuckoo]

So, the "fast track rendering" that Zeldman says browsers give to XHTML - that only applies to XHTML served as application/xhtml+xml, is that right?

Probably not even then. In theory, an XML parser should be a bit faster than an HTML parser. This will most likely not even be noticeable for a normal web page, since other things like download time and rendering take far longer.

There is also another factor that comes into play here. Current versions of Firefox (as far as I know) do not support incremental rendering along with their XML parser. Opera does. I don't know about Safari. This means Firefox will have to parse the entire page before it starts rendering anything – much like the layout tables of old. So the perceived rendering speed can actually be lower in Firefox if you use real XHTML than if you use HTML (including pretend-XHTML).

But presumably a lot of his "top ten reasons" to convert to XHTML actually apply only to XHTML served as application/xhtml+xml?

There are no technical advantages of using XHTML markup if you serve the document as text/html. Such a document must be parsed and interpreted as HTML, so it will, to all intents and purposes, be HTML (with an assortment of syntax errors and extraneous character data).

Some proponents of pretend-XHTML claim that there are 'cultural' benefits, namely that those who choose XHTML markup should be more aware of web standards and accessibility than those who use HTML markup. I've not seen any evidence of this myself, but I cannot disprove it objectively either. What I have seen is tons of bad 'XHTML' pages that would come to a screeching halt if served as XHTML, so at least I can 'prove' that using XHTML markup is no guarantee for standards awareness.

Is this a fact?

That has absolutely nothing to do with XHTML vs HTML. It pertains to web standards vs proprietary markup, though.

[Enoch Root]

Re: the last point about having to serve different versions of sites to different browsers - you're saying there's no reason that a page authored in HTML 4.01 Strict should not be viewable in all sorts of different browsers and devices - I'm thinking mobile devices here. I'd always swallowed the line that XHTML worked in other devices such as mobile in a way HTML would not.

You're saying this isn't true at all?

On a different note, are there any benefits to be had from serving pages as application/xhtml+xml to browsers that understand it, and as text/html to IE?

[AutisticCuckoo]

I'd always swallowed the line that XHTML worked in other devices such as mobile in a way HTML would not.

You're saying this isn't true at all?

Let me phrase it this way: do you think there is a market for a browser that only supports XHTML, not HTML?
It would only be able to render something like .001% of all web sites, namely those that use XHTML markup and serve the documents as an application of XML.

You mustn't try to parse something served as text/html with an XML parser – even if it happens to contain valid XHTML markup. The MIME type is in control.

On a different note, are there any benefits to be had from serving pages as application/xhtml+xml to browsers that understand it, and as text/html to IE?

None, if it's the same page. If you're able to serve it as text/html, then it cannot use any XML features. You may just as well serve it as text/html to all user agents.

[Enoch Root]

Tommy, you should write a book on this kind of stuff!

[AutisticCuckoo]

Yeah, but who'd read it? Not the ones who need to, that's for sure.

[Enoch Root]

Well, I'd buy it

This all sounds a bit like "browser wars 2" - a blind alley down which web development has stumbled.

What do you think should have happened? What are the advantages of XHTML served properly as application/html+xml, always and everywhere?

cheers

[xhtmlcoder]

Advantages would be error handling... However, XHTML is not main the issue, it is the legacy/buggy browsers.

[AutisticCuckoo]

What do you think should have happened? What are the advantages of XHTML served properly as application/html+xml, always and everywhere?

The advantage would be that you can use elements from other XML namespaces inside your XHTML document. For instance, if you want to include some SVG vector graphics or a mathematical equation marked up with MathML.

You could also use CDATA sections and the &#38;apos; entity, but that's probably not enough motivation.
(Technically, there's nothing that prevents the use of CDATA sections with HTML, either, except that most browser don't support it. Opera does, but I don't know of any other.)

If all web pages were to be transformed into XHTML and served as such, then you could build smaller and slightly faster browsers by eschewing the HTML parser in favour of an XML parser only.

The downside would be the draconian error handling mandated by XML. It would most likely stop non-gurus from publishing anything at all, since well-formedness is an absolute requirement. Anyone relying on a point-and-click publishing tool based on re-shuffling text (such as Dreamweaver or Frontpage) would be left behind.

[Enoch Root]

Tommy,

What does this do:-

<meta http-equiv="content-type" content="application/xhtml+xml" />

I've got a feeling that:

• It doesn't do much
• The people who wrote it think it does

It seems to me that if content negotiation happens on the server; so by the time this is being parsed the document is already being served as text/html - is that right?

[AutisticCuckoo]

It wastes a few bytes, nothing more.

As I've said above, you cannot change the content type in a meta element. A user agent needs this information before it starts parsing.

Content negotiation occurs on the server (if at all). It's the server that must send the appropriate HTTP header for real XHTML.

I think this sort of markup is an optimistic approach by someone who doesn't have access to the server configuration or to a server-side scripting language.

[Enoch Root]

Ok, I think I'm getting the hang of it now, thanks. I thought this must be the case since the meta element was present in IE.

Thanks for your time Tommy

[melaniemax]

Thanks Tommy for this I know I'm a little late on the scene but I appreciate it as much as the others!

[Sasha Smaili]

i am not so sure about XHTML but I know a lot about HTML....

[Avery]

That is a big stuff,thanks for sharing.

[Jaynet]

Good stuff,thanks for sharing.