Tags: ie8

8

sparkline

Icon fonts, unicode ranges, and IE8’s compatibility mode

While doing some browser testing this week, Mark come across a particularly wicked front-end problem. Something was triggering compatibility mode in Internet Explorer 8 and he couldn’t figure out what it was.

Compatibility mode was something introduced in IE8 to try not to “break the web”, as Microsoft kept putting it. Effectively it makes IE8 behave like IE7. Why would you ever want to do that? Well, if you make websites exactly the wrong way and code for a specific browser (like, say, IE7), then better, improved browsers are something to be feared and battled against. For the rest of us, better, improved browsers are something to be welcomed.

Shockingly, Microsoft originally planned to have compatibility mode enabled by default in Internet Explorer 8. It was bad enough that they were going to ship a browser with a built-in thermal exhaust port, they also contemplated bundling a proton torpedo with it too. Needless to say, right-minded people were upset at that possibility. I wrote about my concerns back in 2008.

Microsoft changed their mind about the default behaviour, but they still shipped IE8 with the compatibility mode “feature”, which Mark was very much experiencing as a bug. Something in the CSS was triggering compatibility mode, but frustratingly, there was no easy way of figuring out what was doing it. So he began removing chunks of CSS, reducing until he could focus in on the exact piece of CSS that was triggering IE8’s errant behaviour.

Finally, he found it. He was using an icon font. Now, that in itself isn’t enough to give IE8 its conniptions—an icon font is just a web font like any other. The only difference is that this font was using the private use area of the unicode range. That’s the default setting if you’re creating an icon font using the excellent icomoon service. There’s a good reason for that:

Using Latin letters is not recommended for icon fonts. Using the Private Use Area of Unicode is the best option for icon fonts. By using PUA characters, your icon font will be compatible with screen readers. But if you use Latin characters, the screen reader might read single, meaningless letters, which would be confusing.

Well, it turns out that using assigning glyphs to this private use area was causing IE8 to flip into compatibility mode. Once Mark assigned the glyphs to different characters, IE8 started behaving itself.

Now, we haven’t tested to see if this is triggered by all of the 6400 available slots in the UTF-8 private use range. If someone wants to run that test (presumably using some kind of automation), ’twould be much appreciated.

Meantime, just be careful if you’re using the private use area for your icon fonts—you may just inadvertently wake the slumbering beast of compatibility mode.

Dealing with IE again

People have been linking to—and saying nice things about—my musings on dealing with Internet Explorer. Thank you. You’re very kind. But I think I should clarify a few things.

If you’re describing the techniques I showed (using Sass and conditional comments) as practical or useful, I appreciate the sentiment but personally I wouldn’t describe them as either. Jake’s technique is genuinely useful and practical.

I wasn’t really trying to provide any practical “take-aways”. I was just thinking out loud. The only real point to my ramblings was at the end:

When we come up with clever hacks and polyfills for dealing with older versions of Internet Explorer, we shouldn’t feel pleased about it. We should feel angry.

My point is that we really shouldn’t have to do this. And, in fact, we don’t have to do this. We choose to do this.

Take the particular situation I was describing with a user of The Session who using IE8 on Windows XP with a monitor set to 800x600 pixels. A lot people picked up on this observation:

As a percentage, this demographic is tiny. But this isn’t a number. It’s a person. That person matters.

But here’s the thing: that person only started to experience problems when I chose to try to “help” IE8 users. If I had correctly treated IE8 as the legacy browser that it is, those users would have received the baseline experience …which was absolutely fine. Not great, but fine. But instead, I decided to jump in with my hacks, my preprocessor, my conditional comments, and worst of all, my assumptions about the viewport size.

In this case, I only have myself to blame. This is a personal project so I’m the client. I decided that I wanted to give IE8 and IE7 users the same kind of desktop navigation that more modern browsers were getting. All the subsequent pain for me as the developer, and for the particular user who had problems, is entirely my fault. If you’re working at a company where your boss or your client insists on parity for IE8 or IE7, I guess you can point the finger at them.

My point is: all the problems and workarounds that I talked about in that post were the result of me trying to crowbar modern features into a legacy browser. Now, don’t get me wrong—I’m not suggesting that IE8 or IE7 should be shut out or get a crap experience: “baseline” doesn’t mean “crap”. There’s absolutely nothing wrong with serving up a baseline experience to a legacy browser as long as your baseline experience is pretty good …and it should be.

So, please, don’t think that my post was a hands-on, practical example of how to give IE8 and IE7 users a similar experience to modern browsers. If anything, it was a cautionary tale about why trying to do that is probably a mistake.

Dealing with IE

Laura asked a question on Twitter the other day about dealing with older versions of Internet Explorer when you’ve got your layout styles nested within media queries (that older versions of IE don’t understand):

It’s a fair question. It also raises another question: how do you define “dealing with” Internet Explorer 8 or 7?

You could justifiably argue that IE7 users should upgrade their damn browser. But that same argument doesn’t really hold for IE8 if the user is on Windows XP: IE8 is as high as they can go. Asking users to upgrade their browser is one thing. Asking them to upgrade their operating system feels different.

But this is the web and websites do not need to look the same in every browser. Is it acceptable to simply give Internet Explorer 8 the same baseline experience that any other old out-of-date browser would get? In other words, is it even a problem that older versions of Internet Explorer won’t parse media queries? If you’re building in a mobile-first way, they’ll get linearised content with baseline styles applied.

That’s the approach that Alex advocates in the Q&A after his excellent closing keynote at Fronteers. That’s what I’m doing here on adactio.com. Users of IE8 get the linearised layout and that’s just fine. One of the advantages of this approach is that you are then freed up to use all sorts of fancy CSS within your media query blocks without having to worry about older versions of IE crapping themselves.

On other sites, like Huffduffer, I make an assumption (always a dangerous thing to do) that IE7 and IE8 users are using a desktop or laptop computer and so they could get some layout styles. I outlined that technique in a post about Windows mobile media queries. Using that technique, I end up splitting my CSS into two files:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

The downside to this technique is that now there are two HTTP requests for the CSS …even for users of modern browsers. The alternative is to maintain one stylesheet for modern browsers and a separate stylesheet for older versions of Internet Explorer. That sounds like a maintenance nightmare.

Pre-processors to the rescue. Using Sass or LESS you can write your CSS in separate files (e.g. one file for basic styles and another for layout styles) and then use the preprocessor to combine those files in two different ways: one with media queries (for modern browsers) and another without media queries (for older versions of Internet Explorer). Or, if you don’t want to have your media query styles all grouped together, you can use Jake’s excellent method.

When I relaunched The Session last month, I initially just gave Internet Explorer 8 and lower the linearised content—the same layout that small-screen browsers would get. For example, the navigation is situated at the bottom of each page and you get to it by clicking an internal link at the top of each page. It all worked fine and nobody complained.

But I thought that it was a bit of a shame that users of IE8 and IE7 weren’t getting the same navigation that users of other desktop browsers were getting. So I decided to use a preprocesser (Sass in this case) to spit out an extra stylesheet for IE8 and IE7.

So let’s say I’ve got .scss files like this:

  • base.scss
  • medium.scss
  • wide.scss

Then in my standard .scss file that’s going to generate the CSS for all browsers (called global.css), I can write:

@import "base.scss";
@media all and (min-width: 30em) {
 @import "medium";
}
@media all and (min-width: 50em) {
 @import "wide";
}

But I can also generate a stylesheet for IE8 and IE7 (called legacy.css) that calls in those layout styles without the media query blocks:

@import "medium";
@import "wide";

IE8 and IE7 will be downloading some styles twice (all the styles within media queries) but in this particular case, that doesn’t amount to too much. Oh, and you’ll notice that I’m not even going to try to let IE6 parse those styles: it would do more harm than good.

<link rel="stylesheet" href="/css/global.css">
<!--[if (lt IE 9) & (!IEMobile) & (gt IE 6)]>
<link rel="stylesheet" href="/css/legacy.css">
<![endif]-->

So I did that (although I don’t really have .scss files named “medium” or “wide”—they’re actually given names like “navigation” or “columns” that more accurately describe what they do). I thought I was doing a good deed for any users of The Session who were still using Internet Explorer 8.

But then I read this. It turned out that someone was not only using IE8 on Windows XP, but they had their desktop’s resolution set to 800x600. That’s an entirely reasonable thing to do if your eyesight isn’t great. And, like I said, I can’t really ask him to upgrade his browser because that would mean upgrading the whole operating system.

Now there’s a temptation here to dismiss this particular combination of old browser + old OS + narrow resolution as an edge case. It’s probably just one person. But that one person is a prolific contributor to the site. This situation nicely highlights the problem of playing the numbers game: as a percentage, this demographic is tiny. But this isn’t a number. It’s a person. That person matters.

The root of the problem lay in my assumption that IE8 or IE7 users would be using desktop or laptop computers with a screen size of at least 1024 pixels. Serves me right for making assumptions.

So what could I do? I could remove the conditional comments and the IE-specific stylesheet and go back to just serving the linearised content. Or I could serve up just the medium-width styles to IE8 and IE7.

That’s what I ended up doing but I also introduced a little bit of JavaScript in the conditional comments to serve up the widescreen styles if the browser width is above a certain size:

<link rel="stylesheet" href="/css/global.css">
<!--[if (lt IE 9) & (!IEMobile) & (gt IE 6)]>
<link rel="stylesheet" href="/css/medium.css">
<script>
if (document.documentElement.clientWidth > 800) {
 document.write('<link rel="stylesheet" href="/css/wide.css">');
}
</script>
<![endif]-->

It works …I guess. It’s not optimal but at least users of IE8 and IE7 are no longer just getting the small-screen styles. It’s a hack, and not a particularly clever one.

Was it worth it? Is it an improvement?

I think this is something to remember when we’re coming up solutions to “dealing with” older versions of Internet Explorer: whether it’s a dumb solution like mine or a clever solution like Jake’s, we shouldn’t have to do this. We shouldn’t have to worry about IE7 just like we don’t have to worry about Netscape 4 or Mosaic or Lynx; we should be free to build according to the principles of progressive enhancement safe in the knowledge that older, less capable browsers won’t get all the bells and whistles, but they will be able to access our content. Instead we’re spending time coming up with hacks and polyfills to deal with one particular family of older, less capable browsers simply because of their disproportionate market share.

When we come up with clever hacks and polyfills for dealing with older versions of Internet Explorer, we shouldn’t feel pleased about it. We should feel angry.

Update: I’ve written a follow-up post to clarify what I’m talking about here.

Viva

My trip to MIX08 was also my first visit to Las Vegas. I’m sure I’m not the first place to make this observation but may I just say: what an odd place!

I experienced first-hand what Dan was talking about in his presentation Learning Interaction Design from Las Vegas. In getting from A to B, for any value of A and any value of B, all routes lead through the casino floor; the smoky, smoky casino floor. If it wasn’t for the fact that I had to hunt down an Apple Store to try to deal with my broken Macbook—more on that later—I wouldn’t have stepped outside the hotel/conference venue for the duration of my stay. Also, from the perspective of only seeing The Strip, visiting Las Vegas was like Children of Men or a bizarro version of Logan’s Run.

But enough on the locale, what about the event? Well, it was certainly quite different to South by Southwest. Southby is full of geeks, MIX was full of nerds. Now I understand the difference.

I was there to hear about Internet Explorer 8. Sure enough, right after some introductory remarks from Ray Ozzie, the keynote presentation included a slot for Dean Hachamovitch to showcase new features and announce the first beta release. I then had to endure three hours of Silverlight demos but I was fortunate enough to be sitting next to PPK so I spent most of the time leaning over his laptop while he put the beta through its paces.

After the keynote, Chris Wilson gave a talk wherein he ran through all the new features. It goes without saying that the most important “feature” is that the version targeting default behaviour is now fixed: IE8 will behave as IE8 by default. I am, of course, ecstatic about this and I conveyed my happiness to Chris and anyone else who would listen.

IE8 is aiming for full CSS2.1 support. Don’t expect any CSS3 treats: Chris said that the philosophy behind choosing which standards to support was to go for the standards that are finished. That makes a lot of sense. But then this attitude is somewhat contradicted by the inclusion of some HTML5 features. Not that I’m complaining: URL hash updates (for bookmarking) and offline storage are very welcome additions for anyone doing any Ajax work.

Overall IE8 is still going to be a laggard compared to Firefox, Safari and Opera when it comes to standards but I’m very encouraged by the attitude that the team are taking. Web standards are the star by which they will steer their course. That’s good for everyone. And please remember, the version available now is very much a beta release so don’t get too discouraged by any initial breakage.

I’m less happy about the closed nature of the development process at Microsoft. Despite Molly’s superheroic efforts in encouraging more transparency, there were a number of announcements that I wish hadn’t been surprises. Anne Van Kesteren outlines some issues, most of them related to Microsoft’s continued insistence on ignoring existing work in favour of reinventing the wheel. The new XDomainRequest Object is the most egregious example of ignoring existing community efforts. Anne also some issues with IE’s implementation of ARIA but for me personally, that’s outweighed by the sheer joy of seeing ARIA supported at all: a very, very welcome development that creates a solid baseline of support (you can start taking bets now on how long it will take to make it into a nightly build of WebKit, the last bulwark).

The new WebSlices technology is based heavily on hAtom. Fair play to Microsoft: not once do they refer to their “hSlice” set of class names as a microformat. It’s clear that they’ve been paying close attention to the microformats community, right down to the licensing: I never thought I’d hear a Microsoft keynote in which technology was released under a Creative Commons Public Domain license. Seeing as they are well aware of microformats, I asked Chris why they didn’t include native support for hCard and hCalendar. This would be a chance for Internet Explorer to actually leapfrog Firefox. Instead of copying (see the Firebug clone they’ve built for debugging), here was an opportunity to take advantage of the fact that Mozilla have dropped the ball: they promised native support for microformats in Firefox 3 but they are now reneging on that promise. Chris’s response was that the user experience would be too inconsistent. Using the tried and tested “my mom” test, Chris explained that his mom would wonder why only some events and contact details were exportable but not others. But surely that also applies to WebSlices? The number of WebSlices on the Web right now is close to zero. Microsoft are hoping to increase that number by building in a WebSlice parser into their browser; if they had taken the same attitude with hCard and hCalendar, they themselves could have helped break the chicken’n’egg cycle by encouraging more microformat deployment through native browser support.

Overall though, I’m very happy with the direction that Internet Explorer is taking even if, like John, I have some implementation quibbles.

Having experienced a big Microsoft event first-hand, I still don’t know whether to be optimistic or pessimistic about the company. I get the impression that there are really two Microsofts. There’s Ray Ozzie’s Microsoft. He’s a geek. He gets developers. He understands technology and users. Then there’s Steve Ballmer’s Microsoft. He’s an old-school businessman in the mold of Scrooge McDuck. If Ray Ozzie is calling the shots, then there is reason to be hopeful for the future. If the buck stops with Steve Ballmer however, Microsoft is f**ked.

Vegas by Southwest

One trip ends, another begins. In a few hours I’ll be back in Gatwick. This time I’m embarking on a journey to Las Vegas where I’ll be attending a little bit of MIX08.

I’m going specifically to meet the IE team. I was all set to head out there in a fighting stance, ready to fight my corner in the battle against the default behaviour for version targeting. Well, it turns out that I needn’t be so adversarial. I’ve just heard that Microsoft are reversing their position on the default behaviour. So now instead of going to Vegas for a title fight, I’m going to celebrate.

I can’t express how happy this makes me. I’m also extremely impressed that Microsoft listened to—and acted upon—the feedback from the developer community. They can now count on me as a staunch ally in educating site owners about how to implement version targeting when necessary.

Once I’m thanking the IE team from the bottom of my heart, I’ll hop on a flight from Vegas to Austin for the annual geek Summer camp that is South by Southwest. I’ll be in transit on Thursday, spending most of the day hanging around the airport in Dallas. If you’ve also got some time to kill there, send me a direct Twitter message and we can meet up in some corner of the airport.

As is now traditional, I’ve drawn up Adactio Austin: a mashup of microformats and maps that lists all the best parties so you can see how far apart they are. If our paths should cross at any of those geek gatherings, be sure to say Hi and drink a Shiner Bock with me.

It won’t be all beer and BBQ in Austin; I’m also going to be moderating a panel. This is the first time that I’m doing a panel rather than a presentation and I’m quite looking forward to it. After getting together with my fellow panelists at the Social Graph Foo Camp, I’m certain we’re going to have an exciting and fun discussion.

If you’re going to Southby, be sure to make it along to The Great British Booze-up on Monday evening. It was one of the highlights last year and we aim to repeat the success (we being Clearleft, Boagworld and Carsonified).

See you in Vegas and/or Austin.

Fanning the flames

There’s a new issue of A List Apart out today. As Richard put it:

Jeremy dares to clash with the mighty Zeldman.

Though I find Shaun’s description cuter:

Morpheus is fighting Neo!

To be honest, there’s nothing really new in the article I’ve written. In 2000 words, I managed to squeeze out one decent sentence:

The proposed default behavior for version targeting in Internet Explorer solves the problem of “breaking the web” in much the same way that decapitation solves the problem of headaches.

For a better, more impassioned rebuttal of the IE8’s default version targeting behaviour, I’d recommend just reading my original blog post, Broken and its follow-up Still Broken. I’m starting to feel somewhat jaded and exhausted about the whole thing. I can understand why Eric gave up trying to convince Chris and co. that the default behaviour is wrong.

I will be going to MIX08 in Las Vegas at the start of March to meet with the IE team but though they might be willing to listen to opposing viewpoints, I get the sinking feeling that their position on default behaviour is not reversible.

Still broken

It’s been a few days now since the announcement on A List Apart. Since then there has been some good debate but a lot of noise and fury signifying nothing. Eric put it best when he said:

If you feel the need to impugn the integrity or intelligence of another person to oppose an idea, you’re undercutting yourself, not your target nor the thing you oppose.

I think that Jeffrey is right when he observes that there might have been less vitriol expended had this proposal come from anyone other than Microsoft. Still, it’s hardly surprising that the initial reaction to Microsoft’s version targeting is one of shock and rejection. After all, that was also the initial reaction of both Eric and Jeffrey.

Let me clarify what I think of the proposed meta element for version targeting, just in case it wasn’t clear from my previous post:

This proposal is fine. I don’t think it’s great but I think it’s a pretty good solution to a very real problem that Microsoft are facing. As Jeffrey said:

I don’t love version targeting but I see that it serves a need.

That need is ensuring that Microsoft’s customers won’t have to spend time and money jumping through hoops every time that a new version of Internet Explorer is released (as happened with IE7). Yes, I know that if these people—mostly in the Enterprise world of intranets—had just written to standards in the first place then they wouldn’t have had any problems. But that doesn’t change the reality of the situation that those people are in. Any proposed “solutions” that involve abandoning these customers—or, in the more extremist suggestions, abandoning Internet Explorer—simply aren’t facing up to reality.

The http-equiv="X-UA-Compatible" instruction is a solution that requires minimum effort from publishers (although it does require a lot of future effort from the browser manufacturer). The switchover from IE6 to IE7 cost a lot of people a lot of time and money as they scrambled to move from CSS hacks to conditional comments. It’s no secret that Microsoft view this as a failure, hence the new proposal which will ensure that sites can be frozen at the level of IE7 even after IE8 is released.

Microsoft can now provide their customers with a ludicrously simple answer to any future problems. All they have to do is add a meta element to their documents (or set up their server to automatically output that header).

But that isn’t what Microsoft is proposing. Instead, IE8 will behave as IE7 by default. The meta element is required if you want IE8 to behave as IE8. Mark Pilgrim encapsulates the madness of this approach:

  • If you give me non-standard markup, I will render it according to standards.
  • If you give me standard markup, I will not render it according to standards.

Let me make it perfectly clear: I understand the need for version targeting. But the onus must be on the publisher to enable it. The effort required is minimal—much less than any pain that was endured in the move from IE6 to IE7.

On the plus side, future versions of Internet Explorer might not cripple themselves on encountering HTML5 documents. That’s good news for the future. Sometime in the ten years, this will be a solved problem. In the meantime, there will be millions of documents written in HTML 4.01 and XHTML 1.0—both perfectly fine DOCTYPEs. There’s no reason why they should be treated as second-class citizens by default.

Chris Wilson read my misgivings and commented:

However, the problem is that we can’t tell the difference between your content (valid HTML with a correct HTML 4.01 DOCTYPE) and that of someone who hacked up their own content to work with IE6/7 when faced with an IE browser, and whose content will break entirely if we correctly implemented standards as specified.

It’s true that a browser can’t read minds but rather than ship a browser that’s crippled by design, it seems far, far better to me to allow people to tell the browser to regress. I think that asking people to add one meta element isn’t asking too much. As compromises go, it would be a great way for publishers and browsers to meet each other half way.

I believe that Microsoft want to help their customers. I believe they have found a reasonable solution. But in defaulting to crippled functionality in their next browser, they are hurting everybody else.

Jeffrey describes this as an implementation detail but it is far more than that: it is the implementation.

A few years ago, Microsoft introduced some proprietary CSS properties for coloured scrollbars. Fine. Anybody who wanted to make use of this “innovation” was free to do so. The rest of us could just ignore it. Now suppose that instead of making coloured scrollbars an option, they were the default… and if you wanted to revert to the standard way of displaying scrollbars, you had to use the proprietary code. See the problem?

Non-standard browser features are nothing new. Internet Explorer has already given us XMLHttpRequest and innerHTML. We are free to use these or to ignore them. Now, for the first time, a browser feature is mandatory: if you don’t want to use the new feature, you have to disable it… by using the new feature.

Jeffrey is in favour of this proposed default behaviour. He argues very persuasively that it will help the non-professionals who are building websites:

Teachers, pastors, coaches. Managers and owners of very small businesses that can’t afford to hire anyone reading this page to create a snazzy website for them.

I passionately believe that anyone should be able to publish online. That is the vision of Tim Berners-Lee’s beautiful Web. But I don’t think those people will be affected by this decision one way or the other; chances are they are using old-fashioned table-based markup. Besides, they are not the people that Microsoft are trying to help. Microsoft are trying to help the people with money (which is fair enough: Microsoft is, after all, a profit-making business).

I’ve listened to the arguments in favour of IE8 behaving as IE7 as default. I still believe it is the wrong behaviour. Now what can I do about it?

Jeffrey counsels a polite approach:

And, presumably, if enough developers believe the default should be “current version” instead of “IE7” — and if they argue their case coherently and dispassionately — Chris Wilson and his colleagues might come to agree with you, and the version tracking default might end up the way you want it instead of the way it was originally proposed.

If that’s the part that bothers some folks here (like it bothers Jeremy Keith), the thing to do is politely take it up with Microsoft’s Chris Wilson. That’s how stuff changes: by politely talking to the people who make our browsers.

I concur. I hope that the decision regarding default behaviour lies in the hands of people like Chris Wilson and Marcus Mielke. I know that Chris is passionate about standards. I know that if he believes that changing the default behaviour is the right thing to do, he will do it.

Eric agrees with me. Many of the comments on Jeffrey’s blog also agree:

  • I support version targeting but the part that confuses me is that if the tag is excluded, it defaults to IE7.

  • I’m with Jeremy — it SHOULD default to IE8.

  • Many of the comments against the A List Apart articles seem to more or less echo what Jeremy Keith is saying.

  • I think that in IE8 the default should be IE8; but render as IE7 when asked (with version targeting).

  • Make IE8 work like IE8 by default. If your site breaks, then - and only then - add the meta tag to beg for IE7. Adding the meta tag will be easy for the small number of sites that require IE7 (ie. those sites that still ignore the 10-20% of non-IE browsers such as FF, Safari and Opera).

  • After a lot of reading and some hard thinking I think Jeremy is right. The meta could be a useful tool if the default is IElatest, not IE7 8 or any specific version.

  • If you’re going to have a fallback, you may as well use the gold standard in incorrect rendering; the one that the entire web was coded to for 5 years: IE6. If you’re going to implement something as logically backward but seemingly necessary as this version targeting, you may as well do it in the most backward way imaginable.

  • Far better is to force those who made poor choices in the past by working to IE7 implement a simple 1-line fix to get their legacy site to render under the IE7 engine. I’m sure the MS folks can get the message across: “Broken site in IE8? Add XXX to fix it.”

  • I’m also with Jeremy Keith (and others on this).

  • I’m going to go with Jeremy’s request for sites to use the latest rendering mode unless the meta tag say otherwise.

  • The most logical execution for this tag is that when it is not there, it defaults to the latest engine.

  • I really cant agree with the attitude that in order to do things right in a certain browser, you have to go out of your way and add a tag.

  • IE8 rendering *must* be the default in IE8 to further promote standards-based, interoperable websites.

  • IMO, I think they should do it the other way around. Make a flag available to mark ie8 sites into ie7 mode.

  • I am still not clear on why any site I make that conforms to standards has to include a new line of code to make it display according to standards.

  • If you don’t specify this meta tag, you will be served an IE7 rendering engine. Having opt out by default is one of the key arguments for most of the people saying that the suggested implementation of version targeting is wrong.

  • I am in favor of the version targeting, because it seems a very good way to untie the hands of IE’s design team. I am still not convinced by your argument for defaulting to IE7.

  • Making the default version IE7 rather than “edge” seems like a bad idea. If it’s as easy as making a one-line change to your web server configuration (to add the HTTP header rather than the meta tag), then corporations will have plenty of time to future-proof their intranet apps against IE8.

    Adding the versioning capability, but having a default of “edge” gives corporate sites/intranets a way to protect themselves. This allows Microsoft to stop worrying about backwards compatibility and lets them focus solely on implementing the standards correctly.

  • I don’t agree with the direction of the switch; it really should default to IE8 and give people the meta to invoke Trident.

  • The switch is all cool, but it’s opposite of what it should have been. Instead of forcing developers that are following standards to insert this meta element to actually be able to use these standards, Microsoft should reverse the switch so those targeting a rendering engine has to insert it instead.

  • PLEASE, reconsider that default behavior, it is NOT a “detail.”

  • I’m not seeing how the current form of the tag is better for standards over making the tag an opt-in for IE7 rendering.

  • If the default was reversed I think no one would raise so much as an eyebrow for this proposal. In fact most people would positively support it. As it stands this problem is just crazy.

  • Even if IE8 can display everything my style sheet declares, if I omit the META declaration, IE users will get a sub par experience.

  • *”Edge” should be the default, not IE7!* (That’s my new sig ;)

  • If the default behaviour of any future IE version is to render as ITSELF, then surely all lousy developers need to do to fix their sites is put in the required meta tag.

And here’s a cherry-picked sampling from the IE8 blog:

  • I’d prefer having the superstandards mode on by default.

  • SuperStandards should be ON by default. If IE7/quirks mode is needed, the meta tag should be used.

  • Standard should be on by default, or just call your browser ‘IE 7 extended’.

  • I’d prefer having the superstandards mode on by default.

  • I agree, super-standard mode should be the default mode.

  • Let’s have the IE8 Standards mode on by default.

  • Make it an OPTION to work in IE7 or IE6 or whatever mode. But make it DEFAULT to run IE8 “super standards” (this should be called standards mode) mode.

  • Standards mode should be the default.

  • What i think would be a good idea is to turn this exactly around: add a meta tag or http header to sites that need to be rendered by IE8 in ‘crappy-mode’, ‘ie6 mode’ or ‘ie7 mode’ and kick it into standards compliant mode by default.

  • There SHOULD be an option to trigger IE 8 to use old rendering engines but it should be disabled by DEFAULT

  • A site that wants IE8 to behave like IE7 should have to specify the meta tag, not the other way around.

  • Use standards compatibility mode by default.

  • I personally think that you should really consider making the real IE8 engine (“super standards” as some have called it) the default option.

  • So let me get this straight… I have to add an additional meta tag to my page in order for IE8 to support standards?!?!?

  • Standards mode should be the default.

  • Standards mode should be the default if the doctype is declared.

  • Super-standard should be the default, period.

  • I’m coming round to the idea that this is workable *if* the default is changed to IE8 - standards compliance mode - the meta then provides a fix for any site that breaks.

  • As some have previously mentioned, the Standards compliant mode should be the default.

  • All browsers must be in Standards Mode by Default.

  • Please make fully standards compliant mode the default.

  • In case it’s not clear: Make the standards mode default.

  • It’s great that IE 8 will have a much better standards support. It’s bad that it won’t be on by default, requiring a switch.

  • The idea is good. The default is bad.

  • Standards Mode by Default. Standards Mode by Default. Standards Mode by Default. And now repeat!

  • I too think that this is a great idea, but the default behavior is evil.

  • It is fundamentally wrong to stick us with IE7’s broken implementation as a default.

  • Standards should certainly be default, not an opt-in.

  • I’m no web developer, and I never, and I mean never say anything anti MS,but why can’t standards mode be enabled by default?

  • Make IE8 standards compliant by default.

  • Fellas, I really appreciate what you’re trying to do. Improving the renderer was the right thing to do, and you’ve done that. Bravo! The wrong thing to do is to have the correct behaviour require yet another tag.

  • The default when processing a correctly specified doctype should be standards mode.

  • I have to agree that full standards compliant mode should be on by default.

  • I agree that super compliant mode should be enabled by default and the meta tag should be used for Quirks mode.

  • I have no problem with the concept of a meta tag that allows developers to target specific browsers, but the default should ALWAYS be the latest and greatest.

  • After reading the various articles (and comments) on this approach (i.e. the meta tag “switch”) I really think that IE 8 should default to the latest and greatest rendering first - not the IE7 rendering engine.

  • If you do go ahead with this: make super standard mode default please.

I kind of feel like John Turturro to Chris Wilson’s Gabriel Byrne:

I’m praying to you! Look in your heart!

Broken

I’m sure by now you’ve seen the latest issue of A List Apart. Therein, Aaron outlines Microsoft’s implementation of rendering switching based on a meta element and Eric describes how his initial feelings about the technique changed over time.

I’d like to make one thing absolutely clear. You might infer from A List Apart or from the IEBlog that there was collaboration between the Web Standards Project and Microsoft on this. That is not the case. There was collaboration between some members of the WaSP and the IE team but, as Drew makes very clear, most of us were completely in the dark about this. I knew that something was coming but I didn’t know what because Microsoft will only collaborate under NDA. That is not a good situation. NDAs are poison to free and open discussion.

With that out of the way, let me tell you what I think of the proposed http-equiv="X-UA-Compatible" instruction. I think this could have been a great feature—exactly the kind of innovation that Alex was talking about. It could have been a way of solving Microsoft’s fear of “breaking the web” for existing customers who have coded their sites to the current level of browser support—the people who understandably don’t want to have to change their sites when a new browser is released.

Here’s how the X-UA-Compatible works. In a meta element or HTTP header, an instruction such as IE=8 tells future versions of Internet Explorer to render the document as a specific version would (IE8 in this case). In theory, any future versions of Internet Explorer will retain the ability to render documents just as they would have been rendered in previous versions.

This solution was driven by the perceived problems with IE7’s release. Personally, I believe that Microsoft did a great job with IE7 but I know that within the company, it was in some ways seen as a failure. Many customers complained of IE7 “breaking” sites that worked just fine in IE6 (where “break” is usually defined as “not looking the same”). This is a legitimate source of concern for Microsoft. The proposed X-UA-Compatible header will solve this problem. Customers who don’t want their sites to behave any differently in future versions of Internet Explorer can lock down the rendering to the current browser.

So far, so good… great, in fact. But—and this is a huge “but”—if you don’t include a X-UA-Compatible instruction, you are also condemning your site to be locked into the current version: IE7. This is a huge, huge mistake.

Let’s say you’re building a website right now that uses a CSS feature such as generated content. Any browsers that currently support generated content will correctly parse your CSS declarations. Future browsers that will support generated content should also parse those CSS declarations. This expected behaviour will not occur in Internet Explorer. IE8 will include support for generated content. But unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.

I can’t believe I just wrote that sentence. This shouldn’t make any sense:

Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.

That’s madness! If I don’t use the X-UA-Compatible instruction, I won’t get the benefit of any future improvements in Internet Explorer. That sounds like blackmail to me. There is an option to activate whatever is the current browser version—which, of course, should be the default behaviour. This is achieved by using the (strongly discouraged) IE=edge value in… yup, http-equiv="X-UA-Compatible". So even if you want to opt out, you have to opt in. That too is madness.

Just to be absolutely clear on this, I think that the X-UA-Compatible header is a great idea. It’s great for Microsoft. It’s great for Microsoft’s customers. But the default behaviour is wrong, wrong, wrong! This should be an innovative feature, not a mandatory part of the process of creating a document on the World Wide Web. *

IE8 has not yet been released. It’s not too late for this broken default behaviour to be changed. If enough of us make our case clearly, perhaps Microsoft will listen to us… even if we haven’t signed NDAs.

For more on this, please read


*As for all the comparisons to DOCTYPE switching, can I just point out that the reason why I put a DOCTYPE on my documents (and the reason why the WaSP lobbied authoring tool vendors to do the same) is because valid (X)HTML documents require a DOCTYPE; not because it makes Internet Explorer render in a different mode. The tail does not wag this dog. If I write a valid (X)HTML document with a correct DOCTYPE, surely I should expect a browser to render it to the best of its ability rather than crippling itself?