views:

65

answers:

3

I want to use XHTML5 but apparently they two browsers don't accept the application/xhtml+xml MIME type. I read that they will accept text/xml (or application/xml not sure) but it is kind of hackish. So I was wondering if I should just serve HTML5 to IE7 and IE8?

Please don't go on talking about XHTML vs HTML advantages. I know.

A: 

It doesn't really matter so long as you:

  • Use one which triggers Standards Mode
    • HTML 5
    • XHTML 1.0
    • HTML 4.01 Strict ** HTML 4.01 Transitional (but not the short form that omits the URI)
  • Serve code that conforms to the DTD (it makes QA testing that much easier)
    • … or spec if you use HTML 5 (since there is no DTD)
  • Follow the Compatibility Guidelines if you serve up XHTML

Using the same Doctype throughout is generally a good idea.

Serving up as application/xhtml+xml to some browsers and the same content as text/html to other browsers is generally a waste of time and effort.

David Dorward
+2  A: 

XHTML 5 is not a standard. XHTML 2 does prescribe a new doctype, though XHTML 2 is not supported by any modern browsers (as it is largely unfinished).

HTML5Doctor recommends that if targeting an "XHTML5" approach, simply use the HTML5 doctype, which makes sense. The HTML5 doctype is compatible with IE7/8.

http://html5doctor.com/html-5-xml-xhtml-5/

Remember, to use HTML5 (properly) in IE <9, you need to include the HTML 5 shiv.

http://ejohn.org/blog/html5-shiv/

Also, in terms of a MIME type for XHTML5, you MUST serve the content with application/xhtml+xml or application/xml, which older version of IE will NOT support. Thus, if you're trying to take a purist approach, you CANNOT have IE 6/7 support.

mattbasta
As of right now, XHTML2 is an ex-parrot; the W3C [discontinued its working group](http://infoworld.com/d/developer-world/xhtml-2-language-dumped-in-favor-html-5-036). This isn't to say it couldn't be resurrected in the future, but for now you can forget about it.
Zack
“XHTML 5 is not a standard” — in what sense?
Paul D. Waite
XHTML 5 is a pseudo-combination of the XHTML and HTML5 standards. Because HTML and XHTML are not subsets of one another, there are some features of both languages which are lost by combining the two. Some folks consider XHTML 5 to be a combination of XHTML2 (with the ability to, for example, set an `href=""` attribute on any element) and HTML5 (with the new contextual elements). "XHTML 5" is simply an unwritten "compromise" between the two formats.
mattbasta
No it's defined under the HTML5 Spec. Its written. You are right: its not a standard. More like a subset of a standard.
Actually, the HTML5 spec details migration techniques for XHTML to HTML (namely the use of XHTML syntax and MIME types in section 1.7) and instructions for HTML parsers to interpret XML-based markup (namely XHTML in section 11). "XHTML 5" is simply a buzzword. The HTML5 spec clearly states that it does not recommend the use of XHTML (or more specifically, XML markup), as even minor syntax errors should invalidate the whole document.
mattbasta
@mattbasta. «The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines version 5 of the XHTML syntax, known as "XHTML5".» HTML5 draft Section 1.6
Alohci
@mattbasta. Is the above what you mean about not recommending XHTML5, or do you have another quote? I see a caution for the unwary there, but I don't see a non-recommendation.
Alohci
@Alohci: That's what I'm referring to. Minor syntax errors are more than uncommon; just a simple misplaced ampersand can completely invalidate an XHTML document, not to mention any number of encoding errors, errant angle brackets, etc.
mattbasta
@mattbasta. Those things are easily fixed though, because they show up very quickly under testing provided you treat the document as XML at all times. I work a lot in XML, both with XHTML as application/xhtml+xml and also with other applications of XML, and I've never found the demands onerous. Mostly, my XHTML is produced as the last step in a XML-based tool chain, so well-formedness is a given.
Alohci
@Alohci That may be true in many cases, but any time you have user input or data pulled from a remote server, you must be very careful to sanitize properly. Granted, modern browsers account for all of this within XML, but as a matter of being purist, it certainly makes things difficult. Regardless, the snippets that I mentioned certainly don't seem to suggest a new version of XHTML, but rather a means for handling XML-based markup within the HTML5 parser.
mattbasta
+1  A: 

My split-the-difference recommendation:

  • On the server, use an XML-based processing pipeline.
  • But right before you emit the HTTP response body, convert to the HTML5 serialization.
    • That means <!doctype html> and no <?xml ...?> nor xmlns directives.
  • Serve your pages with Content-Type: text/html; charset=utf-8. (Change the value of the charset parameter if you must, but PUT ONE IN, or you risk UTF-7 trickery.)
  • Don't try to condition any of this on the user-agent.

You get the benefits of XML strictness on the server -- you'll notice if you're generating invalid markup, and it makes it much harder to get quoting wrong -- but you don't have to deal with figuring out which clients will actually honor XML mime types.

Note that you can directly embed SVG and MathML in HTML5 even when you're using the HTML5 serialization (the <svg> and <math> elements are magic).

Zack