-
Get a monthly update on best practices for delivering successful software.
Why are we developers still taking a hit for Microsoft's IE6 by doing additional work for it? Well we are certainly not eager about it . "The Market" is directing us by showing us that people use it a lot.
The market says that about 15% of people today are using IE6 which is 8 years old now.
Nothing to be surprised about.
Recently, we at Pathfinder were presented with statistics of usage for a desktop software created in-house showing the biggest drop in workflow at software installation reinforcing the point that people have a hard time installing software, so why would they go around installing a new browser when they already have one? Most people are under the impression that "the site" or "the internet" doesn't work and not the browser they are using and there's nobody there to tell most people what the problem really is.
Continue reading »
Topics: browser, IE, IE detection, IE6, IE8
When a new browser comes out, like IE8, the verdict usually rolls in over the course of a few weeks as our QA testing on various web projects bumps up against its limitations. It's too early for us to render a verdict, but the signs have not been good and continue to be negative.
The evidence continues to trickle in. Louis-Rémi Babé weighs in with his grim assessment:
<canvas>, <svg>, <video> are still missing.To top it all off, Vector Markup Language (VML) is freshly broken. It's one of those sad and frustrating stories. Read up on it here and feel sorry for all of those framework developers who have to crowbar in several hacks for all of the garbage in IE8.
IE6 was a plague upon the Web landscape; we're still dealing with the hacky CSS, HTML and JavaScript that IE6 forced us to write. And there's a handful of dead-enders who just won't let IE6 die, die, die already. So the nearing release of IE8 should be good news, right? Everybody moves up a notch, even the poor sods whose corporate standard is IE6 (crazy, I know).
Not so fast. What made IE6 so bad is that it's bugs became standards. When your site doesn't work, you don't have time to wait while Microsoft maybe pushes a patch (which doesn't take with 50% of the installed base), so you hack the CSS, HTML and JavaScript to make it work. Before you know it, the bugs and other deviations from the standard have become the standard.
Now there are some worrisome signs around the release of IE8. Tables that don't render correctly, JavaScript calls that crash the browser. It's not just the bugs, it's the fact that the IE8 team seems to be giving these bugs the stiff-arm. If IE8 makes it out with a load of these fundamental bugs, they will become the f*cked up baked potato of a standard. And all of us web application developers will be back in 2003. I hated those IE6 days, and none of my clothes from that time fit anymore.
So, if you want to make sure that IE8 isn't a recap of the horrors of IE6, get yourself a copy of IE8 and start providing some feedback. Also, make sure to vote up those bugs that really need fixing. Even if you don't use IE in your day-to-day work, if you develop web software, this is a matter of sanity.
Topics: IE8
I like it. Give me more browser improvements! With the news of Firefox 3.1's JIT JavaScript beasty TraceMonkey, is it too much to hope that IE8 Beta 2 has some similar improvements under the hood?
First you have to find the appropriate page among the 300 or so flogging IE8 Beta 2 in the MS redundaverse. Drilling down into performance, you find the terse:
...the script engine in Internet Explorer 8 is significantly faster than in previous versions, minimizing the load time for webpages based on JavaScript or Asynchronous JavaScript and XML (AJAX).
OK. Faster. Faster how? How much faster?
It used to be that JavaScript engines were so slow that benchmarks served mostly to show that they weren't suitable for anything serious (slow and slower). It's time for some head-to-head benchmarks. Stay tuned.
Topics: IE8, Javascript
At my recent Web 2.0 Expo talk, I exhorted developers to get comfortable outside the Firebug/Firefox safety zone. By rotating between Opera, Safari and even IE as our primary development environments, we can really get to know those browsers - and perhaps learn to utilize their non-standard features. Switching things up, however, can inhibit productivity until you learn your way around each browser's tools.
To that end, I offer these step-by-step instructions for finding computed styles in all four A-grade browsers. I chose the display of computed styles as my "debuggers are cool" use case because it's an obscure but useful feature for CSS debugging. Most of the time I can debug styles by looking at my debugger's snapshot of the current cascade for a given element. But sometimes that's not enough. If I've assigned a value of "inherit" to the font-family of an element, then the cascade snapshot won't tell me what font is actually applied to that element. (Not being a designer, I often can't tell the difference between various sans-serif faces, especially at small sizes.) Luckily, computed styles can give me the information I need.
As these examples demonstrate, debugging tools have come a long way in the last couple of years. Let's make the most of them for all of our UI-layer needs.
500
IE's JavaScript debugging tools have finally matured, but its CSS ones lag behind. Even IE8, with its built-in debuggers (under Tools > Developer Tools), won't show you computed styles. Luckily, Jean-Fabrice Rabaute has crafted DebugBar, an plugin for Internet Explorer 5+ that adds all sorts of useful tools. Install DebugBar, fire up your version of IE and choose View > Toolbars > DebugBar to make the plugin visible. Then click the "DebugBar" icon in the resulting toolbar to open the DebugBar sidebar. You'll see two tabbed panes, one below the other. Choose the "DOM" tab on top and the "Comp. Style" tab on the bottom. In the upper pane, you should see a target icon with the caption "Drag target on document to find element." Drag the icon anywhere on an open web page and you'll see computed styles for the corresponding element in the bottom pane of the sidebar.

Speaking of Really Simple History....
While perusing John Resig's widely discussed analysis of IE8, I was surprised by his lack of fanfare when discussing its support of HTML 5's Ajax navigation module. This is a major development in the arena of Ajax history and bookmark management.
John's comments:
HTML 5: window.location.hash
Already supported fairly well by most browsers. Modifying window.location.hash changes the page URL and adds the page to the history (allowing for back-button simulation in Ajax applications). IE went a step further and broadcasts the hashchanged event (the first browser to do so, as far as I know).
Topics: Ajax Bookmarking, IE8, Javascript, Really Simple History
Unless you've been stuck under a rock for the last week, you've probably heard about the IE8 Beta 1 release. My colleague Brian will have a post or two next week to dig under the surface and tell you what IE8 means to Ajax developers.
Topics: Announcement, Browsers, IE8