XHTML in IE9

Articolo
11/01/2010

IE9 is the first version of Internet Explorer to natively support XHTML. For those not familiar, XHTML is the XML serialization of HTML. Among other benefits, XHTML can help maintain cleaner markup due to its fail-fast nature in the face of parsing errors. You can see IE9 running XHTML for yourself by visiting examples on the Internet Explorer Test Drive site like SVG Helicopter, IE Beatz, and SVG-oids. In this post I’ll share a few details about XHTML and IE9's support for it.

What version of XHTML does IE9 support?

The short answer is XHTML5 (defined by the HTML5 specification). This means that new HTML5 elements such as <canvas>, <audio>, and <video> are all supported by XHTML in IE9. In fact, all of the same HTML (and SVG) elements and attributes that can be used in HTML in IE9 can also be used in XHTML in IE9. Moreover IE9 continues to follow "Same Markup" principles with XHTML just like with other parts of the platform, meaning most of the same XHTML markup should "just work" in the same way across IE9, Firefox, Chrome, etc.

How do I use XHTML in IE9?

Adding a <!DOCTYPE> pointing to an XHTML DTD does NOT influence whether a page is treated as HTML or XHTML. XHTML support for files on the web can only be triggered by the MIME type of the response from the web server. This is true both in IE9 and other browsers. This MIME type should be "application/xhtml+xml" (though you can technically use any supported XML mime type). Local files with ".xht" or ".xhtml" extensions will also be opened as XHTML.

You can verify the correct MIME type was sent to the browser using the "Network" tab in IE9's developer tools. Press F12 to open the tools, click "Start Capturing", and then refresh the page. The MIME type will be listed in the "Type" column for each file received from the server:

IE9 Dev tools, Network tab.

How does versioning impact XHTML?

IE9 will always run documents received with the "application/xhtml+xml" MIME type in IE9 Standards Mode. Not even the developer toolbar can override this behavior. The reason legacy document modes are not supported is because XHTML is new to IE9. Note that this means XHTML documents cannot be loaded into frames unless the parent page is also running in IE9 Standards Mode. These versioning rules also apply to SVG documents received as "image/svg+xml".

How does XHTML differ from HTML?

One of the most notable differences between XHTML and HTML is how parsing errors are handled. Any parsing error in an XHTML document will cause parsing to stop; no fix-up rules are applied. IE9 displays content parsed up until the point at which the error occurred. This is useful during development to catch errors quickly. You can find parsing error details in the "Console" tab of the developer toolbar (note you'll need to refresh the page to see the error if you opened the developer toolbar after the page loaded).

Another important difference is that XHTML is case-sensitive. For XHTML, this generally means that element and attribute names should be lowercased, both in markup and when referenced from script or CSS. Other languages embedded in XHTML may have elements and attributes with mixed case. Such elements and attributes must be written exactly as documented in the appropriate language specification. The "textPath" element from SVG is an example of this.

Yet another difference between HTML and XHTML is that XHTML supports namespaces in markup. This allows integration of XML languages beyond those explicitly defined in HTML5. Note that XHTML requires explicit namespace declarations for each language in use. This means that the root <html> element of an XHTML document must have the XHTML namespace declared in order to be interpreted properly:

 <!DOCTYPE html>
<html xmlns="https://www.w3.org/1999/xhtml">
    <head>
        <title>Sample</title>
    </head>
    <body>
        <h1>Sample</h1>
    </body>
</html>

Any embedded languages require their own namespace declarations as well. This is most easily done by placing the declaration on the start of the embedded sub-tree:

 <!DOCTYPE html>
<html xmlns="https://www.w3.org/1999/xhtml">
    <head>
        <title>Sample</title>
    </head>
    <body>
        <h1>Sample</h1>
        <svg xmlns="https://www.w3.org/2000/svg" width="100" height="100">
            <circle fill="green" cx="50" cy="50" r="50"/>
        </svg>
    </body>
</html>

Note that namespaces can also be associated with elements in other ways, though the approach outlined above generally results in markup that is more portable between HTML and XHTML. For a more in-depth explanation about authoring pages that validate in both HTML and XHTML, see the latest draft of the W3C's Polyglot Markup: HTML-Compatible XHTML Documents.

Next Steps

XHTML can be used today. Just be sure to apply feature detection when using XHTML while still supporting older browsers. Use server-side code to look at HTTP Accept header of incoming requests for the presence of "application/xhtml+xml" to determine if XHTML is supported by the requesting browser. If not, have your server fall back to returning polyglot markup as HTML (or some other reasonable alternative).

 // Pseudo-code for server-side XHTML detection
// Pivots between sending polyglot markup as XHTML or HTML
IF request.headers["Accept"] CONTAINS "application/xhtml+xml"
    // XHTML is supported; use it
    response.headers["Content-Type"] = "application/xhtml+xml"
ELSE
    // XHTML is not supported; fall back to HTML
    response.headers["Content-Type"] = "text/html"

Tony Ross

Program Manager

Comments

Anonymous
November 01, 2010
Are there any advantages in IE9 of using XHTML over HTML, in addition the fact that XHTML is more extensible and cleaner? I am thinking of e.g. speed and features only available in XHTML mode. Thanks, Alexandre http://alexandre.alapetite.fr
Anonymous
November 01, 2010
Will IE9 support XML rendering like the IE6-8 did? The Beta currently does not.
Anonymous
November 01, 2010
Will/does IE9 not advertise support for application/xhtml+xml when a page load is triggered by an iframe in a document that isn't loaded in IE9 Standards mode? Seems important for preserving backwards compatibility with sites that iframe arbitrary other sites that might be in XHTML. If the framed site can't tell whether the browser will be able to handle an XHTML response (can't tell if it's being iframed by a non-Standards mode document or not), sometimes it'll serve an XHTML MIME type and won't be able to be displayed.
Anonymous
November 01, 2010
Wow. IE supports 13 year old technology that everyone else supported 13 years ago. Wow.
Anonymous
November 01, 2010
Rob, XHTML only became a recommendation ten years and nine months ago. Even if we take the first working draft as the metric for age, it's still less than twelve years old. I'm not sure when the first browser implementation came about (I don't care enough to check), but they're certainly younger than the first draft, I'd imagine. You might want to get your facts straight before you go raking mud. Just a thought.
Anonymous
November 01, 2010
Does IE9 behave correctly if you serve an XHTML1.1 page as application/xhtml+xml. What about the differences in the object model, CSS rule interpretation (particularly regarding the HTML element itself), and inline CSS and script parsing rules? Does IE9 behave the same as other browsers for those?
Anonymous
November 01, 2010
Hahaha......yeah ROB. 10 year-old technology is MUCH better than 13 year-old technology.
Anonymous
November 01, 2010
Just got new that IE9 PP6 is top in the Official HTML5 Test Suite Conformance Results test.w3.org/.../report.htm Congrats!
Anonymous
November 01, 2010
The comment has been removed
Anonymous
November 01, 2010
I meant http://www.w3.org/1999/xhtml
Anonymous
November 01, 2010
Developers IE9 work in Redmond?
Anonymous
November 01, 2010
Your detection code isn't standards-compliant. It will send XHTML to browsers that explicitly refuse it: Accept: text/html, application/xhtml+xml;q=0
Anonymous
November 01, 2010
And which browsers would those be, klkl?
Anonymous
November 01, 2010
The comment has been removed
Anonymous
November 01, 2010
Sorry, ".xhtml is not..." should be ".xhtm is not..."
Anonymous
November 01, 2010
Hm, what is a purpose of sending XHTML as text/html? Isn't better just to use HTML 4.x or 5?
Anonymous
November 02, 2010
The comment has been removed
Anonymous
November 02, 2010
Thanks Patrick!
Anonymous
November 02, 2010
@Patrick Yes, RFC3236 doesn't list .xhtm. But, .xhtm is to .xhtml like .htm is to .html. It's an intuitive thing. (Opera supports .xht, .xhtm and .xhtml for local file association and for triggering xhtml mode for local files. I've used both .xhtm and .xhtml, but never .xht)
Anonymous
November 02, 2010
the_dees: "No browser implements XHTML 1.1" So how come my pages, served as XHTML 1.1 to browsers that claim support for XTHML in the accept, header, do work perfectly well in Firefox? Have I missed something? To me it does seem like Firefox supports XHTML 1.1. Actually I believe that Safari, Chrome and Opera do too. Test here: "http://bertilow.com". If you use Firefox or some other modern browser, you'll get XHTML 1.1. So what about MSIE 9? Will XHTML 1.0 and XHTML 1.1 - served as "application/xhtml+xml" - work or not? "XHTML 1.1 is a dead end." That is most probably true.
Anonymous
November 02, 2010
Dear IE team, I am having extreme heartburn using the IE9 beta due to a lack of the green progress bar and how it used to say "Done" when loading a page. The spinning Aero cursor doesn't cut it.
Anonymous
November 02, 2010
@Michael A. Puls II: ".htm" was made up to fit the extension into 3 letters, so ".xhtm" doesn't make much sense as it becomes 4 letters. 2 different extensions for one file type already adds enough confusion as is, no need to add a 3rd one. What if Super XHTML comes up, should 4 different extensions be supported?
Anonymous
November 02, 2010
The iframe element should follow the css border:none and overflow:hidden to hide the border and scrollbar. frameborder and scrolling are no longer allowed in the HTML 5 spec.
Anonymous
November 02, 2010
Hi, "CSS3 Grid Align" will be supported on IE9?! www.interoperabilitybridges.com/css3-grid-align blogs.msdn.com/.../new-direction-for-me-and-the-blog.aspx
Anonymous
November 02, 2010
Where can i find IE9 roadmap? Will be more public betas ?
Anonymous
November 03, 2010
.wdp File and .jxr File.... !!!SUPPORT(.wdp, .hdp, jxr etc Support...) I'm can not Speak English ^^;; Thank you
Anonymous
November 03, 2010
Hello, I downloaded The Newest platform preview and I saw that the buttons on sites like the tweet button on twitter is not round it should be round but it is a square on ie please fix this!
Anonymous
November 03, 2010
The comment has been removed
Anonymous
November 03, 2010
The comment has been removed
Anonymous
November 03, 2010
The comment has been removed
Anonymous
November 03, 2010
the_dees: "Most XHTML 1.1 issues are resolved as of today, the only real issue in my opinion is that it still doesn't allow the lang attribute." I use "xml:lang" as the XHTML 1.1 rules say I should. It seems to work, at least in Firefox. What actual breakage or problems do you see happening? I see none.
Anonymous
November 04, 2010
Firefox's RSS feed reader doesn't update regularly for MSDN for some reason...hm... Well I applaud finally supporting XHTML as application/xhtml+xml however instead of rendering up to an error it would make more sense to not display the page and display an error message instead like Gecko and Presto do. Presto handles it best by allowing the user to render the page as text/html. This has a VERY large bearing on why I test with Gecko first and Presto secondly. WebKit doesn't break the page and I think KHTML doesn't either so I test with WebKit third and up to this point with IE last. Since IE9 isn't available on XP I will continue to test with it last because it's the least convenient requiring tons of RAM for virtualization. Handling the mime with PHP...

<?php if (isset($_SERVER['HTTP_ACCEPT'])) { $mime_ua = stristr($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml'); if ($mime_ua) {$mime = 'application/xhtml+xml';} else {$mime = 'text/html';} } else {$mime = 'text/html';} header('content-type: '.$header->mime.'; charset=utf-8'); echo '<?xml version="1.0" encoding="UTF-8"?>'."n"; ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "www.w3.org/.../xhtml11.dtd">

It should be noted that AJAX content loaded via importNode (innerHTML should NOT be used EVER) should be served as text/xml. I like the idea of NOT implementing quirks mode for XHTML, that's a good move. But limiting IE9 to Vista/7 is NOT a smart move. Want us to "upgrade"? Tell the Windows team to stop removing all the ACTUALLY useful things and shortcuts from Windows. Heck there isn't even an "Explore" option in the context menu on the My Documents or My Computer icon in 7 and I couldn't effectively move the ENTIRE My Documents folder to the D: for a client last week as IE was still saved files to the C:. This isn't guess work or trying to figure out how to one-up Apple, it's listening to users who actually use their machines for production and as power users. Oh and fix IE9's totally borked GUI, less isn't more, it's less. Having you guys actually listen to CRITICAL input besides standards compliance is like trying to tell Linux fan boys to just make the start key with with their version of the start menu. End users and ESPECIALLY people like myself who do production are having to put up with worse and worse software GUI while hardware is getting more and more awesome.

Anonymous
November 04, 2010
@the_dees: XHTML 1.1 supports complex ruby markup whereas HTML5 does not. That, rather than |lang| attribute differences, is probably the most major difference between XHTML 1.1 and HTML5. That problem is more with Ruby Annotations and CSS3 Ruby specs being too vague and poorly thought through than with XHTML 1.1 though, so we may yet see more complete de facto XHTML 1.1 support in the future when those specs have been scrapped or rewritten. There was another difference: modularity (hence the spec title: "Module-based XHTML"). But, given that implementors apparently don't plan to ever support validation against DTDs, that feature is optional per XML, and people can write their own XML schema, that feature has been pretty much invisible and will probably remain that way.
Anonymous
November 05, 2010
@Bertil Wennergren: There is no problem with xml:lang (nowadays). But the xml:lang attribute has had the problem of being unrecognized by browsers or assistive technology. It's not a problem anymore. However, note that in XHTML 1.0 you can use the lang attribute to define the language of an element, and in XHTML 1.1 you can not. Thus both are incompatible. A browser that implemented XHTML 1.1 wouldn't be allowed to look for lang attributes in XHTML documents. It would've to be treated like any other attribute xyz. It works in modern browsers (and even older ones) because XHTML 1.1 documents are simply treated like XHTML 1.0 documents. @Patrick Garies: Let's assue a browser implemented XHTML 1.1 completly (including CSS Ruby and the Ruby Annotations Spec). In this scenario, HTML5 would automatically have Ruby support as well. That is not a thing of specifications but of implementations. And that is the crux of the matter. Something implemented in abrowser will work in any document. But if that meant either one document mode or another (which do not really exist) had a bug, a spec is not implementable. Module-based XHTML sounds nice in theory but it is just a nice concept that wasn't ever needed. Technology evolved way too fast to make this concept needed. You see HTML parsers in mobile browsers. Something no one thought would be possible.

Condividi tramite