“Steve”: Are there any doctypes that do not require this new meta tag to render with the IE8 rendering engine?
Chris Wilson: @Steve - sure. Any unknown (i.e. not widely deployed) DOCTYPE. HTML5, for example.
And, with that, there is no longer any need for me to have to opt-in in order to opt-out of IE8’s new super deluxe bistro quirks mode.
“Steve”: Are there any doctypes that do not require this new meta tag to render with the IE8 rendering engine?
Chris Wilson: @Steve - sure. Any unknown (i.e. not widely deployed) DOCTYPE. HTML5, for example.
And, with that, there is no longer any need for me to have to opt-in in order to opt-out of IE8’s new super deluxe bistro quirks mode.
In 2005, we learned that IE7 will not support XHTML. As of 2006, it appeared that IE8 will not either. Time will tell, but what a pity. I have found XHTML handy as a tool to track down security and encoding issues with my implementation, and outright “oopses” like this one. Like Jacques Distler, I’d be grateful to hear of any other ways Philip Taylor — any anyone else who is so inclined — can find to introduce illformed content into my weblog.
Like Mike Davies, I have come to appreciate Shelley Power’s statement that as of January 1, 2010 she will tolerate nothing less than full spec compliance. I’m reminded of Molly E. Holzschlag’s “Elsewhere” links: Bye bye Netscape. We’ve loved you, we’ve hated you, we’ve pretty much forgotten you by now. It may be time for history to repeat itself. Chris Wilson recently said: We realized that the model for web development was really “write to the standard, then test against and fix problems in the most popular browsers.”
It is time to start the planning process for eliminating that last step.
Thanks go out to Franklin Tse for calling my attention to Chris Wilson’s statement about the HTML5 doctype, and to Sunny ‘Negatif’ Ripert for the icon used above.
It’s worth noting that “the IE8 rendering engine” != “the latest IE rendering engine”. Chris has, I believe, stated in the past that they would not use the HTML 5 doctype as a “always the latest rendering mode” switch and his statement there doesn’t explicitly contradict that position. I would imagine that what will happen in practice is that, around the time of IE 9, they’ll assess how much extant <!DOCTYPE html> content IE 8 will break with the new release, and use that to decide what the new default for HTML 5 content will be.
Optimistically, we can hope that IE 8 is sufficiently close to Mozilla/Opera/Safari in terms of standards support that authors send essentially the same content to all browsers and the IE 8 - IE 9 is like a Firefox 2 - Firefox 3 transition, with only minor compatibility issues between the versions. In that case Microsoft might be happy to leave <!DOCTYPE html> as a flag to use the latest rendering mode.
I don’t understand the implications of Internet Explorer not supporting XHTML. On the RSS Advisory Board site and others when I have the time, I make sure all pages are valid XHTML. Search engines like this better, and I figured the pages would render better in more browsers — which is as far as I want to go with browser compatibility.
Is my decision to create these pages in XHTML hosing them in IE, or is this about IE not parsing these pages as XML and thus missing the boat?
Does
-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN
count as “unknown (i.e. not widely deployed)” ?
Just askin' ...
Optimistically, we can hope that IE 8 is sufficiently close to Mozilla/Opera/Safari in terms of standards support that authors send essentially the same content to all browsers
Optimistically, as more people demand pages that work on mobile platforms, the percentage of time that people concern themselves with continuing to work on legacy browsers will dwindle. IE 9 may very find itself to be in the opposite position that IE 7 was in, with people demanding that the browser by default render pages correctly.
I make sure all pages are valid XHTML. Search engines like this better, and I figured the pages would render better in more browsers
Lots of myths wrapped up in that one statement there. For starters, as long as you don’t serve those pages using the application/xhtml+xml
MIME type, then no browser will render those pages as XHTML. And you will need to be aware of these differences.
I’ve already started my full spec compliance at RealTech, though I need to work on the CSS. Rogers, I’ve not found that the W3C validator is happy when you serve your pages as text/html but your DOCTYPE is XHTML. I usually have to indicate to the application to override the mime type.
I agree with you, Sam, in that it seems unlikely IE8 will have support for XHTML. Frankly, if IE8 doesn’t I think we can assume IE never will have support for XHTML, and we’re at a permanent fork in the road.
Regardless, if one serves one pages up as application/xhtml+xml, we don’t have to worry about using ‘bistro quirks mode’.
Does -//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN count as “unknown (i.e. not widely deployed)” ?
I think it’s pretty unknown, but that may not save you. IE’s current quirks algorithm just looks for substrings ("DTD HTML 4", “DOCTYPE NETSC”, etc), so it’s quite possible that IE8 will extend the same approach. If so, it wouldn’t be unreasonable to expect that anything containing the strings “DTD HTML 4.0” or “DTD XHTML 1.” will be treated as IE7-bug-compatibility mode.
Whatever doctype sniffing method is used, hopefully it will at least be documented better than IE6/7’s method...
“Why do I get the feeling that I have been successfully trolled?”
Sheesh.
Check the RSS 2.0, RSS 0.9 and RSS 0.91 specs and many other static documents and you’ll find they pass. I don’t check these pages automatically — I get around to them when I get around to them.
Do you want to discuss this subject or just find pedantic ways to be dismissive?
I don’t check these pages automatically — I get around to them when I get around to them.
I think that’s the point, Roger.
No one cares whether the page in question was valid. The fact that it wasn’t well-formed means that it could not be served as XHTML.
“When I get around to them” is not a viable mechanism for publishing XML.
Do you want to discuss this subject or just find pedantic ways to be dismissive?
That actually is a credible start. The only substantive issue I found was the use of which would prevent this document from being parsed in standalone mode by XML parsers. This is also an issue when serving such documents as application/xhtml+xml
to Opera.  
is a replacement.
The next issue may be of more importance to you. If you were to serve that document up as application/xhtml+xml
the Google analytics scripts would likely not work. I’m not sure of that as I don’t run GA myself, but I do know that adsense doesn’t work in true XHTML. If that turns out to be of interest to you, I can explore further and make recommendations.
Beyond that, there is an upper bound placed on the usefulness of the W3C validators based on the quality of the relevant specs. A few things in HTML4 and XHTML1 represent wishful thinking, a few things are not implemented by anybody, and the state of the art has progressed since those documents have been written. IMO, the html5 validator, even in its initial experimental status, is based on a much more solid specification, and as such can provide more useful feedback.
Take a look at this example. I changed the doctype, replaced all occurences of
with  
, adjusted the CRLF line terminators, and replaced the one tab in the file with spaces. Other than that, the file is as it was when I downloaded it from your server.
Most of the issues flagged are of the best practices category, in particular: use CSS whenever possible. Some of the issues flagged are more pedantic, and won’t cause issues with most high volume browsers. Whether you care to pursue these recommendations or not is up to you.
Whatever doctype sniffing method is used, hopefully it will at least be documented better than IE6/7’s method...
But “not widely deployed” is, surely, a time-dependent measure. Perhaps IE8 will treat an HTML5 Doctype as “not widely deployed” (and hence exempt from the IE7 bugs-mode). But how will IE11 treat it?
I’m wondering whether it wouldn’t be the most stable long-term strategy to set
X-UA-Compatible: IE=edge
in the HTTP headers (sent to all browsers, as it’s safe to assume that every other browser will ignore this header) and forget about the whole misbegotten idea.
For Google AdSense, this is what I’ve been doing for awhile now in case I one day move to true XHTML:
<object type="text/html" width="468" height="60" data="gads.html" />
Where the referenced gads.html is a HTML document with the appropriate google script elements... seems to work i.e. ads are still contextual to the surrounding page which could be XHTML, right?
<blockquote class="quote">
No one cares whether the page in question was valid. The fact that it wasn’t well-formed means that it could not be served as XHTML. “When I get around to them” is not a viable mechanism for publishing XML.
</blockquote>
I see the point now. I wandered into XHTML for SEO purposes and decided it would help me avoid writing browser workarounds. I haven’t considered all the implications of that move yet.
Firefox is not in this mess. WebKit is not in this mess. Opera is not in this mess.
What did they do differently?
What could IE do to asymptotically approach the state that these browsers are in?
One thing it could do it to pick a DOCTYPE (or, alternatively, pick a mime type) and emulate the behavior (in particular, the setting of expectations) that these other browser vendors have done for this specific doc/mime type(s).
I presume the DOCTYPE being proposed is <!DOCTYPE html>
, and the MIME type, application/xhtml+xml
.
Alternatively, if Chris felt that he and his team could deliver a Standards-compliant browser on a shorter timescale, they could always follow Henri’s suggestion.
I presume the DOCTYPE being proposed is <!DOCTYPE html>, and the MIME type, application/xhtml+xml.
Those would work for me.
Alternatively, if Chris felt that he and his team could deliver a Standards-compliant browser on a shorter timescale
I believe that standards compliance is a process not a destination. No browser vendor will be able to deliver a bug free standards compliant release — ever. The best they can endeavor to do is manage expectations.
Microsoft’s position since 2005 of not wanting to deliver support for xhtml until it can be “done right” effectively means that we should assume that they will never support this mode.
No browser vendor will be able to deliver a bug free standards compliant release — ever. The best they can endeavor to do is manage expectations.
True enough.
I meant a level of Standards compliance comparable to that of the other browsers mentioned, and an expectation that further improvements in its Standards compliance would come at a pace comparable to that of the aforementioned other browsers.
If that doesn’t deserve an entirely new version string, I don’t know what would.