views:

233

answers:

5

Hi stackoverflow,

I'm having a rather heated debate into IE's XHTML Compatibility. The only thing is, I'm unsure if the guy is trolling.

Essentially he claims that IE has absolutely no XHTML compatibility, and that a document with a defined XHTML doctype means absolutely nothing when served as content type text/html, regardless of the browser used.

I do not believe this and sources say otherwise, but I am wrong?

Edit: Disregarding IE, does it still mean that when XHTML is defined in an HTML document it is NOT XHTML? Like the guy suggested? My current understanding is that XHTML is often contained within the HTML content type. This means that technically you could say that XHTML is merely HTML unless the correct content-type is used. But it's still XHTML syntax and so it a little confusing.

You can find the thread in question over at digitalpoint forums.

+6  A: 

IE has indeed no support for application/xhtml+xml content type while other browsers would then handle HTML as XML. When text/html is used, every browser will just handle XHTML as HTML, IE does nothing different here (expect from the usual quirks).

More details here: http://hsivonen.iki.fi/doctype/

BalusC
Disregarding IE though, does it still mean that when XHTML is defined in an HTML document it is NOT XHTML? Like the guy suggested? My view is that it is merely XHTML contained within HTML. Is this not correct?
kahrn
Yes, XHTML put into an HTML document is treated as tag soup.
Broam
XHTML must be considered as "HTML with XML syntax". The actual content type just instructs the browser how to handle the stream. The `application/xhtml+xml` would trigger the XML parser/renderer. The `text/html` would trigger the HTML parser/renderer. IE is senseless for this and just handles it as HTML all the time.
BalusC
@BalusC, thanks for clearing things up. I have re-marked your answer as the accepted answer.
kahrn
"XHTML must be considered as 'HTML with XML syntax'." - That is not stated in the specification, at least not in the XHTML 1.0 specification. I believe you are confusing XHTML 1.0 for XHTML 1.1. Since you are guessing outside the language of the specification I am changing my up vote to a down vote.
It was just an abstract explanation, in an attempt to give the clear picture. Maybe I have chosen the wrong word in "considered". I think "seen" or "visualized" were better in its place. It's a language barrier :)
BalusC
"The application/xhtml+xml would trigger the XML parser/renderer. The text/html would trigger the HTML parser/renderer. IE is senseless for this and just handles it as HTML all the time." - Not completely correct: IE can't handle XHTML served with content-type application/xhtml+xml (it just displays a save box, like with other unknown content types). See for instance http://www.w3.org/MarkUp/2004/xhtml-faq#ie
Marcel Korpel
+2  A: 

The guy is right. When serving XHTML as text/html, is is no longer XHTML, but funny-looking HTML. MIME type is key.

Williham Totland
That is not true. Refer to paragraph 5.1 of the XHTML 1.0 specification.
Yes and no, austin. The syntax is xhtml, and the spec says you can serve it as text/html, but the browser won't recognize it as xhtml and only tag soup.
Rob
@Rob - The browser will recognize it as HTML whether it is HTML 4.01, XHTML 1.0, or XHTML 1.1. So what if it is tag soup, it is still valid XHTML if it conforms to the doctype. If you wish to require that XHTML be processed as XML then use XHTML 1.1 instead of XHTML 1.0. Otherwise you are guessing at things that are not written into the specification, and so you would be wrong and not the person which you claim.
A: 

BalusC is correct. More to the point is that the person you are arguing with is assuming that XHTML must be XML, which is false. XHTML 1.0 is a syntax of HTML that is compatible with XML syntax, but is however an SGML serialization that may optionally be processed as XML per paragraph 5.1 of the specification. XHTML 1.1, however, must be processed as XML.

The idea is that XHTML 1.0 is written as a transitional point between SGML and the XML syntax, even XHTML 1.0 strict. The various doctypes of XHTML 1.0 are all transitional and merely indicate the degree of conformance to the XML syntax without regard for the method of processing.

A: 

The other guy is right. You are wrong. IE has no support for application/xhtml+xml as others have said. IE treats it as "tag soup" when served as text/html as do other browsers.

Rob
Disregarding IE, does it still mean that when XHTML is defined in an HTML document it is NOT XHTML? Like the guy suggested?
kahrn
It is the syntax of XHTML but the browser won't read it that way so trying to pinpoint the wording can be tricky. Some call it "broken HTML" cause that's how the browser treats it, essentially.
Rob
XHTML is a syntax and not a processing scheme. It can be served in the SGML form, which you call tag soup, and still be valid. Whether or not it is processed as XML has no bearing on the validity of its syntax. If you wish to use a form of XHTML that requires processing as XML then use XHTML 1.1 instead of XHTML 1.0.
A: 

I guess this question is done, but:

IE has absolutely no XHTML compatibility

IE won’t parse XHTML content served as text/html as XHTML. (It’ll parse it as HTML.)

Unfortunately, it won’t display XHTML content served as application/xhtml+xml as a web page — it’ll display it just like it displays any other XML content, i.e. prettified source.

As per the XHTML 1.0 spec, you are allowed to serve it as text/html for compatibility with older browsers (i.e. IE). So IE is sort of compatible with the XHTML 1.0 spec. But as many have argued, if you’re not parsing XHTML as XML, what’s the point?

a document with a defined XHTML doctype means absolutely nothing when served as content type text/html, regardless of the browser used

Depends what he means by “means”. It’s still HTML, so it’s got all the meaning associated with that. And as you say, the content is still XHTML, as it’s written in the XHTML syntax. But it won’t be parsed as XML due to the mimetype, so in that sense it’s not XML, and thus isn’t XHTML.

(If you’re wondering what the practical implications of this are, join the club.)

Paul D. Waite