I just came across this article in Smashing Magazine about the CSS differences in Internet Explorer 6, 7 & 8.
Nothing new really, but a good summary of what works and what doesn’t. The consensus is of course that you have to be aware of that IE6 pretty much can’t handle anything, so we’re still bound to write old code to be compatible with it. Sad but true!
I stumbled upon Expression SuperPreview, a really neat tool for comparing different versions of web pages.
It basically lets you enter the URL (local or public) of a web page, and allow you to compare images of different browser versions. Compard to other tools, like BrowserShots, it’s got the handy addition to also inspect and compare DOM elements in the views.
There’s a free, slimmed version available for Internet Explorer (6+) comparisons and a “premium” version included in Expression Web, where you can compare with Firefox and other browsers you may have installed. The premium version is available as a 60-day trial, and the licence is priced at $149 USD, which could prove to be money well spent.
I usually test my apps in IETester and on a virtual machine, but I’ve downloaded the 60-day trial of SuperPreview and will give it a go.
When working with web sites, you often come across compatibility issues due to the users’ variations in browser usage. The vast majority (around 70-75%) of the users still use Internet Explorer as their browser, while most of the development is done in Firefox (thanks to the excellent Firebug and similar tools).
Hence, from time to time you need to adjust your code to make it work in all – well, actually it’s mostly about making it work in IE too, as it’s not as good as the others in following standards – browsers.
A few days ago, I was testing a site in IE (both 6 and 7) and figured I might as well write down the (CSS) issues I came across:
Note that these are only a handful of the issues that you can come across.
Apart from Googling answers to CSS issues, I’ve got a favourite site for finding and solving Internet Explorer related problems: Position Is Everything. After a while, you know these issues by hand, but until you do, it’s really a good place to get help before tearing your hair out…
From time to time, I have a look at various browser statistics to check if there’s been any changes in the usage share of browsers. Even though non-IE browsers take more and more shares on the market, Internet Explorer still rules (with around 70% in average). In some areas, the share is even higher; I worked on a product recently where we had an “IE share” of 97% …
What this means to us as professional web developers, is that all products (sites) must be 100% functional in Internet Explorer. There’s no room for excuses like “but it works in Firefox”. There can be no important features/styles/etc that only works in non-IE browsers.
I read about a lot of web developers saying “ignore IE and develop according to the standards”. Maybe that works for your own personal web site, viewed by 10 users a month. But if you’re running a professional site, supported by a large business, you can’t make it a crappy experience for all the regular users out there who aren’t using the latest Firefox or Safari build. That’s just dumb.
When the non-IE browsers have 95% of the market, we can start talking about ignoring IE and its quirks.
I’m not saying I like fixing IE bugs/quirks, but it’s a part of the job, just like any other task. Firefox (my own preference), Safari, Chrome or whatever are surely awesome browsers, far better than IE. But it doesn’t matter, because it’s only us “experts” and hardcore users that know about it. Your target group doesn’t.
So make it your primary goal to have the site working 100% in IE! If you want to use the extra goodies provided by other browsers, make that the little extra functionality that makes it a 110% experience in standards browsers.
(I do my primary development using FF and Firebug (as it’s much more efficient), and do a test round in IE 6+ when I’m done with the design. )
Hello,
Here’s a long (but hopefully interesting) post about JavaScript performance in Internet Explorer. 
As I had some time over in between sprints, I started looking at the performance of our site in Internet Explorer again. The webapp runs very smoothly in Firefox, but some pages take a few seconds (!) to load in IE, due to its “JavaScript density”. In order to find out what we’ve done wrong, I decided to test changing our core JS framework from Prototype to jQuery. Although, this (alone) didn’t result in any noticeable improvements (in short: there’s been a few tests claiming that jQuery is X and Y times faster in general than Prototype in IE).
There wasn’t (and isn’t) any obvious parts of the code that would slow down the site in IE alone, so I decided to try to find the methods that were slowing it down. To do that, I needed a profiling tool. And finding one of those for usage in IE wasn’t easy (in FF you can always use Firebug’s profiling tool).
After some research, I found:
* AjaxView
* JavaScript Profiler 2.0
None of them gave me the result I wanted, as they provided little or no information on what was actually running slow (although it did show me indications of total mean times).
I knew when I started that YUI provides a Profiling tool, but my first priority was to use a standalone client to avoid having to alter my code. But with no other choices, I decided to try it out, and that was obviously a good choice. I read the docs of YUI Profiler and ProfilerViewer and tested them. Reading and setting up the profiler took about 15 minutes.
The thing about using the YUI Profiler is that you have to manually add the methods to profile, but it was an easy task and probably better/more efficient than profiling everything (as Firebug does) since the noise is heavily reduced.
After a while, it was pretty obvious which methods were running slow in IE (note that they were barely tracked in FF); some basic methods took up to 900 ms at first.
Worst methods from my first profiling iteration:
| Function | Longest (ms) | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | Avg | |
| updateTotalStats | 922 | 828 | 891 | 984 | 875 | 900 |
| roundBrowser.setup | 843 | 675 | 687 | 875 | 735 | 763 |
| initBetProgress | 563 | 656 | 703 | 563 | 859 | 669 |
| initLocaleSelector | - | - | 703 | 563 | 859 | 669 |
After iterating “optimizing-profiling-optimizing-profiling” for a while, I managed to reduce the load times with about 40%, without losing any real feature. It was mostly about modifying CSS selectors (i.e. removing one level in the hierarchy) and making sure some methods were only run if they really had to.
Results after optimization:
| Function | Longest (ms) | ||||
|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | Avg | |
| updateTotalStats (1) | - | - | - | - | - |
| roundBrowser.setup | 110 | 125 | 125 | 141 | 125 |
| initBetProgress | 62 | 63 | 78 | 62 | 66 |
| initLocaleSelector (2) | 0 | 0 | 0 | 0 | 0 |
1) Removed unnecessary call
2) Moved initialization to click
Note that the counts aren’t necessarily 100% correct, as several other factors affect the load time (current memory usage etc).
But anyway, the results were massive and the load times were heavily decreased.
So to conclude:
As mentioned. it’s not always easy to know which those methods are by simply looking at the code (IE always tricks us…).
All “JavaScript dense” pages should be profiled (with YUI Profiler until a better tool is found) in order to find methods with poor performance.
More or less interesting articles/documents on the subject:
http://blogs.msdn.com/ie/archive/2007/08/23/Analyzing-Web-2.0-Applications-with-Ajax-View.aspx
http://research.microsoft.com/en-us/projects/ajaxview/ajaxviewusage-1.aspx
http://www.whitefrost.com/documents/html/technical/dhtml/monitor.html
http://www.newearthonline.co.uk/index.php?page=article&article=338&pagenum=2
http://msdn.microsoft.com/en-us/library/bb250448.aspx
http://www.ajaxperformance.com/2008/02/20/yui-profiler/