Tags: ie8

How to Kill IE11 - What the Deaths of IE6 and IE8 Tell Us About Killing IE | Mike Sherov

An interesting look at the mortality causes for Internet Explorer 6 and Internet Explorer 8, and what they can tell us for the hoped-for death of Internet Explorer 11.

I disagree with the conclusion (that we should actively block IE11—barring any good security reasons, I don’t think that’s defensible), but I absolutely agree that we shouldn’t be shipping polyfills in production just for IE11. Give it your HTML. Give it your CSS. Withhold modern JavaScript. If you’re building with progressive enhancement (and you are, right?), then giving IE11 users a sub-par experience is absolutely fine …it’s certainly better than blocking them completely.

I Used The Web For A Day On Internet Explorer 8 — Smashing Magazine

A fascinating look at the web today with IE8. And it’s worth remembering who might be experiencing the web like this:

Whoever they are, you can bet they’re not using an old browser just to annoy you. Nobody deliberately chooses a worse browsing experience.

The article also outlines two possible coping strategies:

1. Polyfilling Strive for feature parity for all by filling in the missing browser functionality.
2. Progressive Enhancement Start from a core experience, then use feature detection to layer on functionality.

Take a wild guess as to which strategy I support.

There’s a bigger point made at the end of all this:

IE8 is today’s scapegoat. Tomorrow it’ll be IE9, next year it’ll be Safari, a year later it might be Chrome. You can swap IE8 out for ‘old browser of choice’. The point is, there will always be some divide between what browsers developers build for, and what browsers people are using. We should stop scoffing at that and start investing in robust, inclusive engineering solutions. The side effects of these strategies tend to pay dividends in terms of accessibility, performance and network resilience, so there’s a bigger picture at play here.

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.

The impending crisis that is Windows XP and IE 8 by Troy Hunt

A good explanation of the litany of woes that comes from Internet Explorer 8 being the highest that users of Windows XP can upgrade to. It’s a particularly woeful situation if you are a web developer attempting to provide parity. But there is hope on the horizon:

2013 will see the culmination of all these issues; support for IE 8 will drop of rapidly, users of XP will find an increasingly broken web, the cost of building software in XP organisations will increase.

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.

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):

Sass, media queries and support for (older) Internet Explorers. How do you do it? This StackOverflow question asks: stackoverflow.com/questions/1062…

— Laura Kalbag (@laurakalbag) January 3, 2013

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.

Persuading Microsoft to Implement Canvas « Processing.js Blog

The 26 step process required to add +1 to a feature request in IE. Franz Kafka is alive and well and living in Redmond.

isolani - Web Standards: IE8 Blacklist: forcing standards rendering opt-in

Bend over 'cause Microsoft is about to stick it to us standards-savvy developers. Again.

Microsoft breaks IE8 interoperability promise | The Register

Håkon is not happy with the default settings in IE8. Deep in the preferences, "Display intranet sites in Compatibility View" is checked.

Note: Two weeks after this article appeared in A List Apart, Microsoft reversed their position on the default behaviour for version targeting in Internet Explorer.

Proprietary innovations by browser vendors are nothing new. Internet Explorer alone has given us XMLHttpRequest, innerHTML, and colored scrollbars. In each instance, we were free to use or ignore these non-standard extensions. Now Internet Explorer is introducing a new proprietary technology in the shape of version targeting. But this time, the only way to opt out of using the technology is, perversely, to use it.

Ball of confusion

When I first read about version targeting here in the hallowed pages of A List Apart, one point confused me. At the end of Eric’s heartfelt article detailing his reaction to the proposal, the final section seemed to suggest that IE8 would, by default, behave identically to IE7. That can’t be right, I thought. Surely I was misreading Eric’s words. To clarify the situation, I asked Chris Wilson what would happen if IE8 were to encounter a valid, well-formed document with a strict DOCTYPE. My worst fears were realized when he confirmed that the browser would behave exactly as if it were its predecessor.

This is gobsmackingly audacious. Imagine a new version of Word that behaves exactly like the old version of Word unless the document it is processing contains a hidden instruction to unlock any new features. That’s what Microsoft is demanding that web developers implement. Unless you explicitly say otherwise, IE8 (and IE9 and IE10, ad infinitum) will behave exactly like IE7.

My incredulity couldn’t be assuaged by the obvious explanations for this behavior—that Microsoft was being stupid or “evil.” The Internet Explorer team is made up of good standards-savvy developers. They must have a good reason for proposing a solution which, on the face of it, appears so crazy.

Destroying the web to save it

Microsoft’s proposal was triggered by a traumatic event: the upgrade from IE6 to IE7. Internet Explorer 6 languished in the doldrums of non-development for many years. Eventually, spurred on by the encroaching market share of rival browsers, Microsoft released Internet Explorer 7 sporting far better CSS support than the previous version.

Because IE6 stagnated for so many years and because it remained the market leader, a whole generation of websites had emerged that were coded to the quirky but predictable vagaries of that browser. These websites appeared to “work.” That is, they looked fine in the most popular browser on the market. But when IE7 was released, these websites were inevitably rendered differently. IE7, with its improved support for Web Standards, rendered these sites in much the same way as any other standards-compliant browser. Despite a concerted campaign to encourage developers to use conditional comments instead of browser-specific hacks, Microsoft received a barrage of complaints from website owners upset at the way that IE7 had changed the game. This is what the Internet Explorer team are referring to when they talk about “breaking the web.”

That’s a loaded phrase that doesn’t stand up to closer scrutiny. Firstly, what’s at issue here is not “the web” but “some websites”. Secondly, rather than “breaking”, it’s more accurate to say “displaying differently.” Finally, it’s important to remember that we are talking about how websites are displayed in one browser: when the IE team talk of “breaking the web,” what they really mean is that their browser will display documents in much the same way as other modern browsers do. Would that really be such a bad thing?

Won’t somebody think of the children?

On the face of it, being the market leader is something to aspire to. But think of how much responsibility that entails. Would you really want to innovate and push the boundaries when even the smallest changes could cause disruption for thousands of your customers? This is exactly the kind of paralysis that Microsoft is trying to break out of. The version targeting proposal is a good solution to this deadlock. With the addition of one meta element, websites can specify exactly how they should be rendered (in one browser).

Furthermore, had Microsoft implemented the X-UA-compatible instruction in IE7, they could have saved themselves a whole mess of trouble. Instead of requiring developers to revisit their style sheets and strip out their browser-specific hacks, they could have instead told website owners to simply add one line to the head of their documents. While it’s hard to imagine that the move from IE7 to IE8 will cause the same upheaval, it’s reassuring to know that Microsoft has thought ahead. Version targeting allows site owners to freeze rendering (for one browser) to a specified browser version. That’s a good thing. While it probably won’t affect standards-savvy developers like you or me, it offers a simple solution for site owners who don’t want to worry about the future. Better still, the fact that the X-UA-compatible instruction can be sent as a header means that this issue can be taken care of by sysadmins with one small tweak to their server configurations.

But even that is asking too much, according to Microsoft. Instead of asking that developers who want to opt out of future improvements do so with the addition of a meta element or header, Internet Explorer expects standards-savvy developers to actively opt out of version targeting… by using version targeting.

The reasoning here is that less savvy developers shouldn’t have to worry their little heads about adding one extra line to their documents. Instead, they should be encouraged to continue to write to the quirks of one specific browser version from the market leader. That their documents will “break” in other browsers is not Microsoft’s problem. The counterpoint to this condescending worldview is that standards-aware developers are the ones best placed to add a single line of markup to their documents—though, for some unexplained reason, the instruction for up-to-date rendering (IE=edge) is strongly discouraged.

This strategy is doomed to failure. Standards-aware developers, by their very nature, will object to adding a line of unnecessary markup to their documents just to get one single browser to behave as it should by default.

Fear of drowning

While most of the web development community saw the release of IE7 as a welcome return to form, within the corridors of Redmond it was viewed as a failure. Microsoft simply cannot afford a repeat of the IE7 upgrade. Version targeting is a technology born of fear. A fear of “breaking the web”—which really means “rendering some websites differently in one browser”—has prompted the draconian default behavior.

Whether this fear is well-founded or not depends on just how drastically IE8 is going to “break” existing websites. Personally, I’m rather puzzled: what exactly are they planning to add in the next version of their browser to make the web asplode? If IE8 is going to differentiate itself from its predecessor by having better standards support, then surely we can assess how it will render websites by simply viewing those websites in a standards-compliant browser like, say, Firefox, Safari or Opera.

Lonely at the top

There was a time when Friendster was the biggest social networking site on the web—MySpace and Facebook were little more than distance glimmers on the horizon. There was a time when Netscape Navigator was the undisputed king of browsers and Internet Explorer was laughable challenger playing catch-up. On the World Wide Web, the status quo is a mutable, shifting thing. The proposed default behavior for version targeting is predicated on events that took place during a short span of years when Microsoft, having emerged as the top dog, pulled the plug on its own browser. There is an unspoken assumption that the only meaningful way the web is experienced is through one browser: Internet Explorer.

We are being told that the default version targeting behavior is necessary because without it, the web will turn into a messy crime scene of breakage (in one browser). If Microsoft are to be believed, the self-crippling default behavior of IE8+ is necessary to save the web (in one browser). Whether you agree or disagree with the default behavior comes down to faith: faith in Microsoft accurately foretelling the impact that IE8 will have.

I would much rather base my judgement on facts. There is an easy way for Microsoft to prove the necessity of mandatory version targeting: release a beta version of IE8 with version targeting disabled by default. Then we can see just how badly the web breaks some websites render differently in one browser.

I’ve listened to and understood all of the arguments in favor of the proposed default behavior: all of them assume that without self-crippling, IE8 will make a mess of a significant portion of the web. If that fear is borne out by an uncrippled beta release of the browser, I will back the proposed default behavior. Until then, I ask that Microsoft honor their promise from many years ago and allow their browser to render a valid, well-formed document with a current DOCTYPE to the best of its abilities.

Future imperfect

Version targeting is not a bad idea. The choice of delivery mechanisms—meta element or server header—is inspired. As an optional feature, this could prove to be a real lifesaver in some development environments. As a mandatory millstone however, it strikes a blow against progressive enhancement. [1]

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. In its current state, version targeting is a cure that will kill the patient. Version targeting could have been an opportunity for Microsoft to demonstrate innovation. Instead, the proposed default behavior demonstrates a fundamental misunderstanding of the World Wide Web, a place that according to its creator, Sir Tim Berners-Lee, will always be a little bit broken.

Footnote

[1] On the plus side, as-yet unpopular DOCTYPEs such as HTML5 can be used to trigger up-to-date rendering from future versions of Internet Explorer. That’s reassuring for the future but HTML5 is not ready for use today—any DOCTYPE that still includes the font element still has some issues that need to be worked out. Besides, once HTML5 is widely deployed, Internet Explorer will probably freeze its rendering for those documents too.

Translation From MS-Speak to English of Selected Portions of Joel Spolsky’s “Martian Headsets” [dive into mark]

Mark Pilgrim fisks Joel Spolsky. He's not greedy either: there's still plenty of straw men left in Spolsky's screed for the rest of us to skewer.

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.

IEBlog : Microsoft's Interoperability Principles and IE8

Praise Jeebus! The IE team are doing the right thing regarding the default behaviour of version targeting in IE8. Thank you, thank you, thank you!

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.

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.

A reasoned response to X-UA-Compatible • Gated Logic • nevali.net

A nice analysis and skewering of Microsoft's proposed default behaviour for version targeting.

The B-List: X-No-Thanks

A superbly clear analysis of the proposed default version targeting behaviour in IE8+.

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!

Microsoft koan [dive into mark]

The madness of the default behaviour in IE8 explained in a beautiful koan.

Katemonkey.co.uk: X-UA-Lemur-Compatible

The timeline behind Microsoft's latest announcement.... as told by stuffed lemurs.