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.