Why Do You Serve Your Xhtml Documents As Text/html ? Options

[Dor]

Hi,


w3schools.com and w3.org XHTML documents are served as text/html.
That happens with FF3.5, which explicitly permits (in the Accept HTTP header) serving XHTML docs.

Why don't you serve them as application/xhtml+xml ?

Thank you.


Regards,
Dor.

[AElliott]

You should serve it as application/xhtml+xml really, unfortunately if you want the page to work in IE you don't have that option. Until IE has wide-spread support for that MIME, XHTML will have to be served as text/html for browser support reasons.

[Ingolme]

Because Internet Explorer doesn't accept the XHTML MIME type.

That's why I use HTML instead of XHTML in my pages.

[Dor]

Indeed, but FF3.5 accepts XHTML documents.
Still, FF3.5 gets an HTML document.

Why not serving as application/xhtml+xml if possible?

[Ingolme]

Most likely because there's not a single advantage in doing so.


I'd ask a better question:
Why use XHTML when HTML does exactly the same things and is always served with the correct MIME type in all browsers?

[Synook]

Indeed, but FF3.5 accepts XHTML documents.
Still, FF3.5 gets an HTML document.

Why not serving as application/xhtml+xml if possible?

Because XHTML implementations are still inconsistent.

This post has been edited by Synook: Nov 1 2009, 01:01 AM

[justsomeguy]

Besides all of those reasons, how about this: they probably haven't even set up the server to do content negotiation to determine the correct mime type to send. The reason they probably haven't done that is probably listed above. The w3schools.com site looks like it's served by a Windows Server 2003 machine running IIS6, I don't think there are any free plugins for IIS to do that. They would have to write ASP code to check for and handle that aspect, and I don't think the benefits of doing so are worth the time required to implement and test that.

The W3C is a different story though. Considering that they have pages like this online:

http://www.w3.org/2003/01/xhtml-mimetype/content-negotiation

... which describe techniques for content negotiation in Apache and PHP, and considering that their site is served by Apache 2 and is using PHP, I'm not sure why they would choose not to use it, even just as an example. Maybe the W3C is too busy working on the Emotion Markup Language.

[boen_robot]

I'd ask a better question:
Why use XHTML when HTML does exactly the same things and is always served with the correct MIME type in all browsers?

Because XHTML can be parsed by XML parsers, whereas HTML, in the common case, can't. If XHTML served as text/html works just the same as in application/xhtml+xml, there is no reason not to use it.

This post has been edited by boen_robot: Nov 1 2009, 05:00 PM

[justsomeguy]

Because XHTML can be parsed by XML parsers, whereas HTML, in the common case, can't.

Why does that matter? Is there a practical example where a browser using a properly-served XHTML page has more functionality than a browser using a regular HTML page?

[Ingolme]

Because XHTML can be parsed by XML parsers, whereas HTML, in the common case, can't. If XHTML served as text/html works just the same as in application/xhtml+xml, there is no reason not to use it.

Well, the problem comes with malformed XHTML documents being accepted just because they're not being parsed by the browser. A lot of people use XHTML as if it was HTML. XHTML documents that have scripts in them using reserved symbols such as &, < and >, a lot of people forgetting to close elements like <p> and <li>.

If suddenly browsers started parsing the XHTML pages as XML half the internet wouldn't work. In fact, one good reason not to use XHTML is because in order for it to display in standards compliant mode you have to omit the <?xml ?> declaration.

I'd be fine using XHTML but I'd only do it if I could send it with the correct MIME type (I did make an XHTML 1.1 page once where I only served it as text/html for Internet Explorer). Usually if you want to parse XML it's because you're storing data, so you won't really need to use XML functions in an HTML page because HTML is just used to display information.

[boen_robot]

Why does that matter?

Screensrapping, mashups, plug-ins, various kinds of engines (e.g. search engines)... all of that is made easier and less error prone for 3rd parties when the page looks like XML (the MIME type is irrelevant). From your side as a developer, there practically aren't any benefits, since you'll have direct access to the database or whatever.

Is there a practical example where a browser using a properly-served XHTML page has more functionality than a browser using a regular HTML page?

Properly served XHTML has the benefit of namespaces, and inherently, the ability to hold one document type into another. The most obvious example - XHTML+SVG+MathML. However, if you just serve THAT kind of document as text/html (without any processing that is), you lose all of those benefits, without any good and easy way of recovering from it on the client side. And that is precicely why even sites that use content negotiation don't utilize those "extras".

Properly formed XHTML has no benefits over the equivalent HTML (or at least, as I said already, not from your point of view). However, there are no drawbacks to it either.

In fact, one good reason not to use XHTML is because in order for it to display in standards compliant mode you have to omit the <?xml ?> declaration.

That is only true for IE6. And besides, with or without the XML prolog, if you use UTF-8 as your encoding (as you should anyways), there's no need to insert the XML prolog to begin with (not even for proper XML parser's sake), as UTF-8 is the default encoding for XML parsers, and you should specify it with the HTTP header. If you want to cover offline access as well, you can insert the meta equivalent. XML parsers will ignore it, and use UTF-8, whereas HTML parsers will read it, and use UTF-8... correct either way.

This post has been edited by boen_robot: Nov 1 2009, 08:16 PM

[Dor]

Most likely because there's not a single advantage in doing so.

If so, why did they write XHTML documents? Why not writing HTML documents? Even the DTD points on the XHTML flavor. (though the DTD declaration is irrelevant to our subject)

Because XHTML implementations are still inconsistent.

What do you mean?
XHTML 1.0 "compatible" HTML document must be presented as if it was an HTML document.
So no presentation differences are expected.
If you mean that IE still doesn't support the XHTML mime type, then I would say: FF2-FF3.5 does support it!
So, why not sending XHTML mime type to FF and sending HTML mime type to IE ?
The document's presentation in both browsers should be very similar.

----------
BTW, thank you people for contributing your knowledge in this thread, but I prefer you to stick with the subject. Thank you (IMG:style_emoticons/default/smile.gif)

This post has been edited by Dor: Nov 2 2009, 08:48 PM

[boen_robot]

If so, why did they write XHTML documents? Why not writing HTML documents?

Because there are no disadvantages to using XHTML from W3Schools' point of view, and there are potential advantages from 3rd parties' point of view. I think this alone justifies it.

XHTML 1.0 "compatible" HTML document must be presented as if it was an HTML document.
So no presentation differences are expected.
If you mean that IE still doesn't support the XHTML mime type, then I would say: FF2-FF3.5 does support it!
So, why not sending XHTML mime type to FF and sending HTML mime type to IE ?
The document's presentation in both browsers should be very similar.

Agree.