At Loss for Words

There are few choices that the engine needs to make:

1. Choose the value for the content-type HTTP header
2. Decide whether to introduce page with a XML declaration
3. Detect if the PNG images can be used

A) content-type

This one is easy. All modern browsers that correctly support XHTML explicitly enumerate the application/xhtml+xml in the HTTP Accept header. For browsers which do not, the text/html is sent for the backward compatibility.

Note that Sprocket also passes that content-type in the <meta http-equiv="content-type" tag.

B) XML declaration

Why do we need to suppress the XML declaration sometimes? IE6 will back into quirks mode and render as IE5 if the document starts with anything else than Document Type Definition (<!DOCTYPE). All common browsers other than IE6 (and older) will handle the XML declarations.

But this is, in the end, even easier to determine than the content-type. Browsers that accept application/xhtml+xml obviously do know XML, ergo suppressing XML declaration whenever we serve the page as text/html will suffice.

Note that there is an exception to this rule. IE7 does not accept application/xhtml+xml, yet it won't fall back into quicks mode on XML declaration. Pay no attention to the IE7 and you are still safe. IE7 does not even parse it, this is documented by MS, it just skips it.

C) Use of PNG

Throughout my investigation of PNG support in browsers I have again discovered that there are rules of thumb. Browsers that accept application/xhtml+xml always support PNG (well, except text-mode browsers). Otherwise the browser declares that support (image/png) in the HTTP Accept header.

And again there are three exceptions to these rules, namely IE6, IE7 and IE8. So if the user agent header contains 'MSIE 6.0', 'MSIE 7.0' or 'MSIE 8.0' then safely assume PNG support too.

Conclusion

And this way Opera, Chrome, Firefox and IE9 gets to see XHTML 1.1, while to the IE6 it is all just HTML4 with strange DTD and unexpected forward slashes before right angled brackets.