Microsoft backs off XHTML support in Whidbey

(Via InfoWorld) In an article at the ASP.NET Developer Center, Microsoft outlines significant changes between the current Beta 2 release of ASP.NET 2.0 (codename Whidbey) and the final Release to Manufacturing (RTM) version due to ship in November.

Though Microsoft is downplaying the significance of most of these changes, one that really caught my eye was the removal of XHTML 1.1 support. Currently, Beta 2 renders XHTML 1.1-compliant markup by default, with options to revert to non-XHTML-compliant output (e.g., <br> instead of <br />). Instead, the final release of ASP.NET 2.0 will output XHTML 1.0 Transitional markup by default, with the option to render XHTML 1.0 Strict or non-XHTML-compliant markup.

Why the change? Microsoft is a little vague on this front, citing the need by many developers who rely on outdated client-side scripts that require a name attribute on the form tag. The use of this attribute was discouraged in HTML 4 and officialy deprecated in XHTML 1.0. The attribute is not permitted at all in XHTML 1.0 Strict or XHTML 1.1, so rendering XHTML 1.0 Transitional by default gives the most modern default output possible while still permitting the use of this attribute.

But as mentioned above, Microsoft still plans to support a “strict” rendering option in ASP.NET 2.0 that produces XHTML 1.0 Strict output. Why not continue to support XHTML 1.1 in this rendering mode?

The answer to that remains unspoken, but I believe it can be summed up in two words: Internet Explorer. The W3C recommends that XHTML 1.1 content be served with the application/xhtml+xml MIME type, which Internet Explorer 6 does not support. At this stage, there is no reason to believe that Internet Explorer 7 will support it either.

In another article on ASP.NET Developer Center, which provides an impressively broad guide to building standards compliant ASP.NET 2.0 applications, SuperExpert.com’s Stephen Walther has this to say on the subject:

There is one glaring problem with the W3C’s recommendation: not all browsers recognize application/xhtml+xml. In particular, Internet Explorer (the most popular Web browser in the history of the world) does not recognize the application/xhtml+xml MIME type. Therefore, serving your XHTML pages using the recommended application/xhtml+xml MIME type is not a viable option.

Whether the “glaring problem” is the W3C’s or Microsoft’s is a debatable point, but by removing XHTML 1.1 support from ASP.NET 2.0, Microsoft seems to be bowing to the wisdom of the W3C. If ASP.NET 2.0 were to output XHTML 1.1, it would need to serve it using the older text/html mime type supported by Internet Explorer, which would be in direct violation of the W3C’s recommendation.

While on the surface it may seem that Microsoft is taking a step back in standards-compliance, in fact it is demonstrating a healthy respect for Web standards by acknowledging that it must bring its “most popular browser in the history of the world” up to scratch before adopting XHTML 1.1 in its Web application platform.

Update: Tom correctly points out in hist comment that the problem with IE is bigger than a lack of support for the new MIME type. Indeed, the fact that Microsoft hasn’t rushed to implement such support naively is another good sign. Microsoft appears to understand that the application/xhtml+xml MIME type should be implemented in tandem with geniune support for XHTML–which Internet Explorer also lacks.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.sitepoint.com/ mmj

    I realise this seems pedantic, but the XHTML problem with Internet Explorer is not that it doesn’t support the application/xhtml+xml MIME type, but that it doesn’t support XHTML at all. Claims that IE doesn’t support the application/xhtml+xml MIME type makes it sound like it could be solved with one line of source code, but it’s not as simple as that. When IE encounters XHTML content it will parse it with an HTML parser (actually, a tag soup parser). It has real implications. For instance, when receiving XHTML, IE can’t cope with CDATA sections, XML stylesheets, or XML processing instructions – all aspects of XHTML that have no equivalent in HTML.

  • Pingback: Pig Pen » Microsoft Backs Off XHTML Support In Whidbey - its an adventure

  • http://www.lowter.com charmedlover

    The whole XHTML issue has really pissed me off in my situations. In my latest project development I have to have a script to apply the correct MIME type to only browsers that can handle it. While I don’t mind this, I don’t like the idea of feeding tag soup to a browser – it just isn’t XHTML.

    This was one of the major factors that would cause me to remotely like IE7.

  • Milan Negovan

    Personally, I welcome this change. I’ve discussed with Microsoft folks potential problems with XHTML 1.1 before. I’m glad they pulled the plug on 1.1 for now.

  • Pingback: Stinkbug.net » Blog Archive » Microsoft backs off XHTML support in Whidbey

  • pwpaust

    they should have released IE 7 with asp.net 2.0 (make sure that IE 7 completely complies with standards)

    bad project management…

  • pavel

    they should have released IE 7 with asp.net 2.0 (make sure that IE 7 completely complies with standards)

    bad project management…

    IMHO, They release IE 7. Good project manager:)