15 December 2011
It’s a Christmas miracle!
Today we are sharing our plan to automatically upgrade Windows customers to the latest version of Internet Explorer available for their PC. This is an important step in helping to move the Web forward. We will start in January for customers in Australia and Brazil who have turned on automatic updating via Windows Update. Similar to our release of IE9 earlier this year, we will take a measured approach, scaling up over time.
Posted in Browsers | No Comments »
15 September 2011
The first big blow to Flash was Apple’s iOS. Now Adobe Systems’ browser plug-in faces another major threat to its relevance: Microsoft has banned it and all other plug-ins from the “Metro” version of Internet Explorer 10.
Metro is the modern “touch-first” interface that plays a starring role in the radically new look of Windows 8, which Microsoft plans to release in 2012. Microsoft will ship the new OS with two versions of IE10, one for Metro and one a brushed-up version of the current Windows 7 interface. While the legacy version of IE10 will accommodate plug-ins, the Metro won’t…
Posted in Browsers, HTML5 | 1 Comment »
2 June 2011
Google Apps already dropped support for IE6 a while back; now they’re taking it a step further, by only supporting the “current and one previous” versions of each browser:
As of August 1st, we will discontinue support for the following browsers and their predecessors: Firefox 3.5, Internet Explorer 7, and Safari 3. In these older browsers you may have trouble using certain features in Gmail, Google Calendar, Google Talk, Google Docs and Google Sites, and eventually these apps may stop working entirely.
IE7′s usage has already dipped below IE6′s in some reports, so this isn’t as huge a deal as it might have been even a year ago. Still, I wish they’d extended this policy out to YouTube as well; that would really drive people to upgrade.
Posted in Browsers | No Comments »
11 May 2011
Thank you, Google. This should really help those people trapped on IE6 by their IT departments.
Posted in Browsers, IE6 | No Comments »
4 March 2011
Credit to Microsoft for creating this.
Posted in Browsers, IE6 | No Comments »
14 October 2010
I’ve been working lately on an app that will only be used in-house, so we can simply exclude browsers that we don’t wish to support. Moreover, there is no business- or marketing-driven reason to insist on a fully-polished UI that looks the same across the board. The result? Graceful degradation in IE 7 and 8. IE users get square corners and no drop shadow? Big whoop. IE’s interface looks boxy and lumpy? Oh well.
Man, this is a freaking joy. There’s simple, clean CSS3 all over the place. How I look forward to the day when IE9 has broad support and I can start doing this kind of thing on lots of public sites as well. Sadly, Microsoft has announced that IE9 won’t run on Windows XP, which is currently about half of the Windows installs out there, so IE8 looks to be the “IE6 of the future”.
Posted in Browsers | No Comments »
30 September 2010
I’ve been working on an internal project lately where I am the only presentation-tier developer, which is not unusual here. What is unusual is that the application is lots of JavaScript and Ajax; most of our stuff leans far more heavily on server-side Java.
There are certainly still differences in browser implementations; heck, dealing with cross-browser CSS is a lot of What I Do™. And there are certainly differences with JavaScript methods as well. However, the brand-name JavaScript libraries exist, in part, to flatten out and deal with the latter. If you’re using one of those libraries, you can rely on it to account for those differences under its hood.
Thus it was with some surprise that I saw a code check-in yesterday that added client-side browser sniffing… and if you were on anything other than IE, would prohibit you from logging in.
After cleaning up the pile of exclamation points that streamed forward from my eyeballs and littered my desk, I began investigating. It seems that in developing the app, the team had hit a few points where IE and Firefox were behaving differently with regards to JavaScript. The team was concerned that having to do cross-browser development would add lots of development time, and since this is an internal project (and thus we can dictate what browsers are permitted), the team decided to settle on one browser, picking IE.
I feel pretty strongly about browser agnosticism, and also feel pretty strongly that browser-sniffing code is inevitably fragile and tricky (I prefer “duck-typing” based on feature). More importantly, I argued, while there are browser differences with JS, if you’re using a library (which we are, namely jQuery), those things don’t tend to come into play unless you’re dealing with something complicated. If you’re coding up Google Maps, sure — but our application is fairly modest and not at all bleeding-edge. The browser differences we were encountering involve straightforward features, the kinds of things that the libraries should be accounting for… so this suggested there’s an underlying, deeper problem. Blocking a browser to avoid these issues would just be putting a band-aid on a deep wound.
Sure enough, the problems were easily remedied. In one instance, the code was checking to see if a form field was enabled by seeing if the field had a value of “enabled”. The issue? The code should be checking for a boolean of true or false, not a string value of “enabled”. One of the browsers would let you get away with this; the other would not. Changing the code to check for a boolean solved the problem. In another case, updates to a page were showing up in Firefox but not IE. IE, it turns out, was caching Ajax data; a jQuery setting of "$.ajaxSetup({ cache: false });" took care of it.
Once we checked in with the business owner about browser preferences, fighting for browser agnosticism turned out to be the right thing to do. We learned that half the user base for this application uses Firefox, and we’d really have annoyed them if we’d forced them to use IE for this application. The browser-sniffing code got removed today, as did the prohibition on non-IE users. Glad I took a stand!
The lessons here:
Posted in Browsers, JavaScript | No Comments »
26 August 2010
IE6 turns nine years old tomorrow. Ironically, it’s now old enough to ride most rides… and those rides are turning it away. The latest is PBworks, formerly PBwiki. They’ve announced that IE6 users are about to start getting a warning message that they have two months to upgrade.
Here’s the intriguing part: after that date, they will be directing IE6 users to their mobile site. And that, I admit, is a solution I hadn’t considered. Most mobile browsers, after all, have stronger standards support (and better security) than IE6. But most mobile sites also offer stripped-back functionality, making them frequently compatible with IE6′s limited standards. If your mobile site has scaled-back features, and those features aren’t especially demanding on modern browser features, punting your IE6 users to m.yoursite.com can be a great way to get rid of headaches.
Posted in Browsers, IE6, Mobile | No Comments »
21 July 2010
This humorous graphic speaks 1000 words.
Posted in IE6 | No Comments »
1 July 2010
IE9 has announced they’re giving decent support to the <video> tag. And that, my friends, spells the beginning of the end for Flash.
I’m a Web-standards guy, so my inclination has never been toward Flash anyway. Admittedly, there are some things for which Flash is ideally suited — namely, for animation and video. To date, there really hasn’t been a reliable way to do that kind of thing, other than the fairly ubiquitous Flash plug-in.
My big beefs with Flash, though, are:
The latter has become a real issue now that I have an iPhone. Sites with Flash splash pages, but no HTML “skip this” link, prevent me from seeing their site. Sites done up entirely in Flash, as is very common for musicians and artists, prevent me from seeing anything. Recently, while driving, my wife and I thought about visiting a new restaurant nearby, so we called up their site to see their menu. The site was all Flash. That restaurant lost business that day — and we still haven’t eaten there. If you can’t be bothered to give me your menu in HTML — a text medium! — I can’t be bothered to find ways around the all-too-familiar iPhone brick icon.
Now, when I mention the iPhone, neither here am I defending Steve Jobs. On the one hand, his public position that the iPhone wants to support HTML5 over proprietary standards is a good one. His refusal to allow Adobe’s tools to export into an iPhone-friendly format, insisting that iPhone developers use only Apple-endorsed tools, shows his real motives.
But Jobs is right about one thing: HTML5 is a big win. With it, we get video, audio, and lots of other good stuff that, to date, has required us to use Flash. IE has, as always, been the laggard; that IE9 will support these HTML5 technologies is a big win for the Web. Mind you, it’ll be years and years before IE6-8 have been suitably flushed out of our system, but we’ll at least be able to plan for the future.
HTML5 doesn’t do everything that Flash can, as Ajaxian points out. Flash will do full-screen video, for instance, which none of the browsers will currently do for HTML5 video. That, however, is a problem for the browser makers, not a problem with HTML5. Hop to it, ye browser coders!
Posted in Browsers | No Comments »