I relate it to a driving experience. One in which I drive to a certain destination often enough, that I become more and more familiar with the route that takes me there. I learn the best streets getting to and off the freeway system, every exit along the way. I know the interesting segments, the boring stretches. Most importantly, I start to recognize traffic patterns, and can predict the areas of congestion that will slow me down. No matter which route I take, there’s usually one portion of the trip where I know I’ll slow to a crawling pace. Some routes can’t be avoided, and the delays they bring must be factored into the total time I think the trip will take..
Such is often the case when designing with CSS. When working with semi-complex layouts, I frequently encounter challenges that end up slowing me down. I’m getting familiar with these road blocks, and can often predict where I’ll find them. Having patience, or knowing what to try to get around them prevents head from going through monitor.
Without a doubt, the biggest challenge I encounter each time is in wrangling Microsoft’s Internet Explorer browser. This devil does not play fair. It often follows no rules, and its behavior defies all common logic. It will double margins for no apparent reason. Borders disappear, 62 pixels magically turn into 143 pixels. It dodges left when other browsers go right. I’ve decided to call this phenomenon “the IE Factor”. (Those familiar with authoring DHTML four or five years ago already know where I’m headed with this.)
While working on the final stretch of a client project last week, I got stuck in a patch of quicksand. Design was finalized long ago. The bulk of CSS was authored over the holidays. Mozilla, Firebird, Safari, and Opera were all rendering the design beautifully, give or take a few small hiccups. But the design still had a few major quirks in IE (both Windows and Mac versions). “Ok, no problem — I need to spend an hour or so squashing bugs in IE.” That hour turned into two full days. Days filled with head-scratching and mind-numbing deconstruction and isolation of declaration blocks and properties. Progress came to a screeching halt while I tried every trick in my book. Solving one problem revealed another. Making a fix for IE would throw off the other browsers. Tweaks that should have worked had no effect, prompting me to try things that made absolutely no sense to try. And lucky me, IE/Win and IE/Mac have completely different bugs.
To be fair, IE/Mac has a predictable set of bugs which have known workarounds. But as I stated above, IE/Win will defy all common logic. Which makes it such a difficult browser to troubleshoot. I don’t dwell on the box model problems in version 5.x. Those can be dealt with. It’s the idiosyncrasies of IE5.0, IE5.5, and IE6.0 together (or in different combinations) that will drive a CSS author mad.
At times, I thought about writing every one of my style sheet rules using child selectors, filtering IE/Win out completely and serving it the same unstyled version as Netscape 4. But of course, IE possesses too much market share to turn off a design for every person using it. My client couldn’t — and wouldn’t — agree with that type of decision. So I had to compromise on each bug. If I couldn’t find an acceptable solution, or beat IE into submission, I’d decide to turn off that feature or design attribute just for IE/Win. Nice hover effects over those icons? Sorry IE, you won’t get them. A nice little bottom border on this box, like EVERY OTHER BROWSER renders correctly without going into convulsions? Sorry IE, you don’t get that either. You’re too fragile for a simple border. What kills me is the extra markup I’ll sometimes give in and add, just to get IE to render a critical part of the design correctly.
On numerous occasions, I’ve been bogged down by Internet Explorer’s incomplete support of CSS. I spent an extra 2 weeks trying to figure out why IE was bungling the Wired News layout. I should have known that I’d encounter difficulty with my project last week. But those two days of lost time hit me hard. I was over-confident that I could catch anything IE threw at me, thinking I could solve it quickly and easily. Silly rabbit. In reality, I’ve now calculated the IE Factor can add upwards of an additional 10% in time and cost for each project, distorting the estimating process if it’s not figured in.
So, you could say I’m becoming familiar with the route. I’m learning the best paths to tread when constructing designs with CSS. I know the interesting segments, the boring stretches. Most importantly, I’ve started to recognize patterns, and can predict the areas that will slow me down. Specifically, I know about the IE Factor. I don’t like it one bit, but at least I can prepare, and expect to encounter it for each project. And I’m building up an arsenal of weapons for use against IE when it misbehaves in the future.
The browser wars are supposedly over. We’re supposed to be at peace now. Everyone is supposedly cooperating. We’re supposed to be living in an era where we don’t need to alter code and make unique design decisions for each browser. We’re close, but I don’t think we’re there yet.
Update: See one example of a bug which contributes to the IE Factor, described in detail in this entry.
66 comments (Comments closed)
Thank you for the article. It’s actually encouraging for a beginner to hear that professionals are driven up a tree dealing with IE. I thought that I just didn’t understand the math involved, but it seems NOBODY understands it. Again, thanks.
would css be as much fun without ie?
Doug, this entry couldn’t have been better timed. I’m sitting here scratching my head over a number of IE 5.0/5.5/6.0 rendering inconsistencies for a client job - having myself fallen foul of the dreaded IE factor. I’d wager we’re not alone. Perhaps a future entry/ALA article on IE factor avoidance techniques? (hint hint :-)
My site visitors sent for me a complaint that they can not click on links, but i still can’t understand why “i can” click on them! we both use IE6! anyway, its a bug in IE6, because i use RTL direction, but when i test it in LTR direction everything was ok.
and sorry for my poor english :-)
Due to an IE 5/5.5/6/Mac display problem on one of my recent projects, I had to resort to nesting a BMH inside an IE/Mac hack. The code is ugly to look at, but having the site look like it should was worth it. Good article.
For anyone who hasn’t gone through the days of wrangling and testing and generally punishing Virtual PC and your MSDN Operating Systems/Browsers licenses, Tantek and Dracos are great starting points for answers.
Last week I was scratching/banging my head over IE 5.0/Win’s decision to wrongly center text (other versions didn’t). Turned out it was an attribute selector filter I’d put in to allow Mozilla/Opera/Safari “overwrite” a rule for IE 6:
*[align="center"] { text-align: center; }IE 5.0, alone, incorrectly read the selector as applying to all elements, not just those with the specified attribute.
The only thing saving the community from unimaginable pains is the ability to finally run multiple versions of the browser on Windows.
When things get out of hand with IE this is my new preferred tactic (lets pretend its something as simple as the margin discrepancy on an input tag):
/*\*/margin: 1px !important; /* For competent browsers*/
margin: 0 1px; /* For IE */
If IE Mac is playing nice I just omit the escaped comment hack.
Isolating quirks is not fun - maybe a good argument to have the tricky-trio open and ready for testing when developing.
I lost a lot of time isolating some IE space bugs.
For example how
p:first-letter {works in IE 6, but
p:first-letter{doesn’t, yet they both work in IE5.5. Arrgg!
Right I know the stuff. My way to have the IE render My Way (tm) is: no parent - child stuff I define each and every single thing. Yes shure .css file grows like hell but you know: you use IE you mess things up :) Still the market reason for IE is extreemly strong especially here in Europe
I can definitely relate to this subject. While I have my current project working in Mozilla, Opera and even IE6 for Windows(haven’t tested Macs yet), IE5.x has been a different problem all together.
I sat down on this past weekend figuring I would only have to fix the box model and font sizes, and perhaps a few float corrections here and there. Wow, did I ever fall into the black hole of death. There were so many rendering problems with both 5.0 and 5.5 that I was working non-stop all weekend, and it’s still unfinished. It just amazed me so much how even the simplest margin declarations and such are just completely ignored. I’ve definitely worn out Google with “css ie5 bugs” queries lately.
I will second the motion for an ALA article highlighting major IE roadblocks and bugs.
Seems to be a common topic of late.
It would be nice to see an article highlighting major roadblocks and bugs.
It may have already been done and if so, please point me to it so I can bookmark it. Otherwise, if someone whats to tackle it, give me a ping, I’m pretty sure Digital Web would publish it.
I’ve compiled a nice set of simple hacks that target different OS/versions of IE:
To target IE5/Mac I make sure some element in the DOM of the page has two or more class names (i.e. the class attribute contains a space). This triggers the horrendous IE/Mac Whitespace Parsing Bug which can be used to your advantage to target IE5/mac specifically. Say we have an element set to
class="wrapper foo", then the rule.wrapper-ie5mac { color : red; }will color that element red only in IE5/Mac. (The “-ie5mac” bit is just random crud that I add to the actual class-name).To target all Windows versions of IE, I use the old “underscore hack”. The invalid declaration
_height : 1em;will only be applied by IE/Win. This particular declaration happens to solve most - almost all - cases of dissappearing borders and backgrounds in IE. Another common fix seems to be_position : relative;The third and final trick I use targets only Windows IE versions 5.0 and 5.5. This tricks combines the “underscore hack” and the “
/**/comment hack”. The underscore includes only IE/Win and the empty comment before the colon excludes IE6.0, leaving only the 5.x browsers to apply the declaration. Example of use:_width /**/: 200px;which seems to be the smallest/simplest “box-model hack” available.BTW, I’ve not 100% verified yet that the above hacks don’t have unintended consequenses in some of the older versions of Opera or - say - old versions of OmniWeb, or the 4.x line of IE. Frankly, I don’t really care if they do. Getting the job done on time (factoring in the damned “IE factor”) is difficult enough, without taking all the extreme minority browsers into account too. Sure, I’m as anal retentive about cross-browser compliance as the next guy - but only up to a point. Hey, sue me! :-)
I’ve been squishing bugs in IE in the holydays too.
Maybe it’s the time to build an ActiveX module that would allow us to use the Mozilla rendering engine in IE… anyone want to start coding?
IE has issues. But what about Netscape 6.2? Is anyone else running into major problems with this browser? Especially involving absolute positioning. My company is insisting on supporting it. Anyone else have this type of experience?
Other Doug: In my opinion, Netscape 6.2 is not worth supporting to the final detail. Try your best to make it work, but I think most folks from the now defunct Netscape team would admit that 6.anything was incomplete and a hurried release. Since 7.x has been out for a while, 6.x traffic should be slowing to a crawl.
Haven’t you wished to tell a client “Screw your IE! Here, get Mozilla/Firebird or Safari instead. They have those cool tabs, by the way”?
I’ve had. Specially because this is something that never can be explained to a client in a convincing manner enough without you sounding like someone that isn’t trying hard enough, when in practice it is totally the opposite. Plus, they won’t understand.
It is this endless wrangling with IE’s quirks that have refrained me from going overboard with CSS design-wise. Now I try to keep my layouts simple enough to cut on the number of hiccups as much as possible, but it is still quite a headache. And your 10% overhead rate is pretty conservative, Doug - I’d rather say 15% to 20%, based upon experience.
It is unfair that IE, whose superiority today lies in market share alone, keeps the webstandards/CSS field from making further progress. Not that this is breaking news…
Thank you for that. I’ve only recently progressed to completely CSS, standards-compliant design, and have devoted days to making my layout work in IE 5/Win. It is encouraging to know that the professionals I admire encounter the same difficulty.
I wish there was a midpass filter of sorts for ie 6 or all of ie. right now i tend to use the *html hack. I know it is not css compliant but either is IE compliant in rendering css.
Thanks for sharing Doug!
This morning, I just had this nice little borders separating inlined list items. The nice little borders (and their padding) weren’t working on IE 5.0.
“A quick hack”, I thought. Turns out it wasn’t hackable.
I can’t say “Sorry IE, you won’t get them”. It’s 35% on my site stats. Even my client’s boss might be using it!
So it’s 8pm right now, and I’ve JUST finished converting my inline list items to floats, which also involved weird trickery to get the thing right-aligned again.
My original CSS was clean, short, intuitable by any guest. Now, it enjoys 15 extra lines of conditional code, and scary hacks for various dinasties of browsers.
I used to think if we could just get past NN4 we’d be in good shape. Boy was I wrong. Since ditching NN4 and pushing the limits again I found what we’ve all found: That IE is the weakest link. If only we could say goodbye.
If there’s anything good to come from Longhorn, a new IE may be it. But by the time that comes out, and we still have to hope it has good CSS 2 support, other browsers will be touting their CSS3 support. *Groans*
Ahhh, so it’s not just me. What a relief.
The problem with this situation of course, is that it turns off people who are new to css. I’ve lost a lot of time, and therefore money, learning how to get css working in six different browsers, when a simple table would have done the job easily. Yep, I know all the advantages of css and I’ll continue to make sites this way - but occasionally I find myself hankering for the simple old days when I just fired up GoLive …
Thanks for the article. Now back to that damn Win IE bug …
It’s a pipe-dream, I know, but it would be interesting to see what would happen if many high-traffic sites just stopped supporting IE. Period. Text-only, no CSS. And maybe a big
<h2>telling people they are receiving a stripped down version because their browser does not support web standards. Again, I know it would never happen, but one can dream… :)I spent almost two weeks last year getting this site up-and-running in IE6/Win. It was easily the most frustrating (and the most expensive) two weeks I can remember. An unbelievably demoralizing and infuriating experience.
Since then I’ve used simpler layouts with no parent-child code (which, of course, kills about 50% of the CSS punch). My only real hope is that, since IE isn’t getting developed for another few years, Apple will fill the gap with Safari for Windows. Maybe we should start a petition.
I know how you feel I recently started the inital build for a site here at work, and ie Mac was being a pain in the arse. You needed one thing for ns6.2 to work but if you changed it to work in ie5.1 on the mac it broke in ns6.2 vice versa. After a good solid hour of tinkering I found a way around it and had it working.
I start my development in Firebird and move from that testing in ns6.2/7.0 & ie5.0/5.5 pc & ie5.1 on the mac
I can now spot where things will break in IE5.0/5.5 and 90% of the time it works in ie5.1mac ns6.2/7.0 and to get around the older ie issue the box model hack comes in handy, esp when you have to get div elements to read exact measurements.
So much time can go into fixing IE CSS bugs, it’s ridiculous. Maybe IT guys don’t mind having all those Windows/MS bugs in their networks and system as much as web developers mind IE’s irrational and neurotic ways of dealing with CSS. I really just want to get on with making a site better, finishing it, solving human problems if necessary, not dealing with some bugs so irrational, they’re barely documented. Most of us, I think, have other jobs to get on with. We’re not always getting paid to deal with those bugs and when we are, it’s the client’s budget that is drained. Using web standards minimizes the individual customization of sites for each browser, but IE makes sure it’s less so.
Well, the Browser Upgrade Campaign was successful, but now it looks like we need a “Kick IE” campaign. At least to put some pressure on IE. Was IE 5/6 condoned by the BUC, by the way?
Lucas:
1. If the Browser Upgrade Campaign was genuinely successful, those of us closest to the action have yet to receive the news. It was quietly yet quickly de-emphasized because the don’t-blame-us mechanism was abused by no end of reprobates.
2. IE/Win was never endorsed. Each version was declared an improvement over its predecessor, but the only iteration of IE to get a WaSP endorsement was 5.x for the Mac. Likewise for Opera 6, Opera 7, and every gold release of Gecko. I’m not sure about Safari… Doug? (Windows is my primary OS.) Also, a point of interest: IE5/Mac and Opera 6 each have a metric boatload of problems with W3C DOM implementations.
3. The issue of robust CSS2+ support in future releases of IE/Win has consumed quite a bit WaSP brainshare, I assure you.
4. Public anger about IE/Win’s shortcomings will ultimately alienate more people than it attracts. For that reason I simply tell anyone who asks that my primary/dev browser is Firebird. ::wink::
Don’t forget that many of these problems come from IE’s extensive quirks mode. A proper doctype can force it to behave better, although of course not perfect, but recently I’ve been finding as many problems in Opera/Safari as exist in IE.
Also, we seem to forget what we once used to do. not that long ago we had browser version checks in our code, specifically script, but also in ASP/PHP server side to get around problems in different browser versions. Why not do that with CSS? I feel that CSS hacks are going only good for the known browser versions. You don’t know how a new release will behave, as they might fix some of the bugs and all of a sudden you end up with some other browsers hacks in your IE code, for example. Hack make for maintenance nightmares IMHO. Why not conditionally generate your CSS using server side script so that what gets sent is always clean for that browser? Why not present blank CSS for browsers that you officially don’t support, so that the users gets plain unstyled HTML, rather than a completely garbled presentation that does the site owner no favours at all?
Ben, thanks for making that last point:
4. Public anger about IE/Win’s shortcomings will ultimately alienate more people than it attracts.
Although I realize I left the opportunity to slam IE/Win wide open in these comments, this entry was not intended to be a “let’s all bad-mouth IE” thing. Certainly, you can sense the frustration in my words, especially when I emphasise them with ALL CAPS. :-)
However, this entry was intended to draw attention to the fact that there is an IE Factor. And that dealing with IE/Win ultimately takes extra time that I’ve often forgotten to “factor” into time estimates. It’s a reality that I’m facing and accepting. I merely wanted to call out this reality, give it a name, and let others know they’re not alone if they find themselves struggling with IE toward the end of the CSS authoring process.
As for an article on how to avoid the IE Factor — that’s just it, I don’t think it’s avoidable in many cases. Just when I think I know how IE/Win will behave in a certain situation (based on previous experience) I’m wrong again. It’s not predictable, and its behaviour changes based on surrounding and containing elements, element order, and various properties of all page elements. Anyone who has repeatedly dealt with IE bugs can probably tell you it varies almost every time. That’s the rub. It’s why I don’t see the IE Factor reducing in percentage over time (with increasing experience). Each project I tackle, the requirements vary, as does the CSS. Each time, seemingly incomprehensible bugs show up. Some are bugs which I’ve never seen before.
As an encouragement to any beginning CSS author, some of the bugs I’m seeing, many of you will never ever see or deal with. I’m often pushing the limits of CSS, dealing in nested floats 3, 4, 5, and even 6 levels deep. Not many people have use for creating (or doing the math on) that kind of complexity. Unless I write about a technique that uses such complexity. But by then, I’ll have discovered a workaround, and I would publish it with the same article.
Holly and Big John maintain some nice explanations and workarounds for some of the predictable IE quirks.
i find it completeley the other way around, i can create sites in IE that render correctly, with moz/opera etc throwing elements all over the place - i guess that you’re bound to one set of rules, and im in with another… e.g.
border widths are added inside ie elements, but outside moz ones, you know about the padding/margin differences, moz messes with line-height which can cause issues etc…
web design
another thing… you all (above) seem to be forgetting that over 90% of browsers are using IE! just because you dont doesnt mean you should discount it…
Hi Doug, long time no see here…
You say 10%. You’re an optimistic guy.
Last week I did the most complex CSS-driven design I’ve had to grapple with so far.
A simple unordered list that had to be floated or absolute-positioned turned into a five-hour-long nightmare. (to end up in unordered links in a simple div for lack of time)
And I’ve still got one or two display bugs in Opera7, too, although I think I’m heading in the right direction towards understanding where I pushed it too far (don’t right-float a list and then left-float its elements in order to have a nice horizontal list, because they’ll stack on top of each other).
All in all, what I had predicted would last one day actually lasted more than *twenty hours*.
How’s that for time-consuming hacking.
I’m not angry at the people who developed IE, of course. In their time they were very advanced when compared to the rest of the market, let’s not forget that.
But it’s true that now that standards-compliant browsers have become quite numerous, IE 5-6 feels reminiscent of NN4 a few years ago, with all the frustration associated.
Well, since people here and at Asterisk* keep asking, here’s a link to a Mozilla ActiveX control:
http://www.iol.ie/~locka/mozilla/control.htm#download
(link courtesy of Erik A. of Web-fx)
The best solution to this problem that I’ve found is to do all initial development work in IE5 then get the same page to work in Firebird.
Next take the page and fix any probs that have been introduced in IE5.5 and 6 - there’s always a few odd quirks in 6 - whilst keeping it working in the other two before moving on to other browsers.
Pain in the rear end, I know, and a long drawn out process but it’s by far the best method for getting those tricky layouts working in all browsers.
Andy: The best solution to this problem that I’ve found is to do all initial development work in IE5 then get the same page to work in Firebird.
That’s the exact opposite of the advice I’d give. I’d never recommend anyone start with IE, let alone IE5! Unless you’re just pulling my leg, starting with IE5 is the worst thing anyone could do.
Of any of the current “in-use” browsers (and I’m ignoring Netscape 4), IE5 has the worst support of CSS of all of them. If you start with IE5 and get everything working ok there, you’ll be working backwords. Start with a buggy browser, and you’ll end up with buggy CSS. And you’ll be learning buggy CSS, which may be the worst part of that.
Start with a stronger browser that gets a lot more correct, and you’ll start off on the right foot. Then it’s just a matter of dealing with the quirks of the more buggy browsers.
Just because a browser may have the largest market share is no reason to use it as the gold standard when constructing a site. Sure, it has to look good in IE. But I’d advise anyone to start with “high” standards, (Mozilla, Firebird, Opera, Safari) and let the design gracefully degrade to less-compliant, more bug-ridden browsers (IE6, then IE5, NN4)…
I’m totally with Doug on this. I posted a comment recently on Keith’s Asterisk that covers my own thoughts on testing.
“I used to think this too [develop in IE, then test in Mozilla], but there’s a good reason why my mindset shifted. If you develop in IE first, and then test elsewhere, what happens is that you create dependencies on IE’s buggy rendering.
Since the other browsers don’t use the same flawed rendering, you’ll have to bend over backward to hack your layout into working properly with most of them. In fact, when I was developing in IE, I used to curse Mozilla quite frequently for rendering my code ‘wrong’.
My experience has been that if you start out by developing in Mozilla or Safari, and then test in everything else afterward, you have to do much less hacking to make it work. The fringe browsers benefit; IE5/Mac gets a surprising number of my layouts right without any extra effort. Opera generally cooperates, although it can be a crapshoot at times. IE (per the general tone of this thread) is the big problem.
Can you get away with developing in IE? Of course. Is it easier? Generally not. If you don’t care about the fringe browsers, then you’ll get away with it. If you do care, then you’ll have a far nicer time by developing in Mozilla. Hope that helps.”
I’d definitely have to agree with Andy there. While coding for the majority might be worthwhile, it is also asking for trouble once it comes time to do some maintenance. My site that I have right now is basically free of bugs (that I’ve discovered), however it took days just to fix all of them in IE. I coded for Mozilla Firebird, then put in some nasty hacks to fix it for IE.
Frankly though, after reading this, you gave me the motivation to do what this guy did on his Zen Garden entry (view it in IE). Obviously putting it in an image isn’t the greatest idea, but the concept is definitely good - let IE people know that, first off, Mozilla is better, and second that if there are bugs in your page then it’s IE’s fault. Sounds like a good idea to me…
I have been working on one project that works in both Mozilla and IE 6.0, is displayed OK in IE 5.5 (with box hacks used) and shows up totally messed up in IE 5.01 and lower, I guess I just stopped suupporting IE 5.01 since it cannot handle the easy task of interpreting the CSS properly.
You can see it (temporarily) at:
http://www.bra3v3ku.sk/absolut/
Check with Mozilla and IE.
Doug you made my day because I’m still discovering the holly grail of IE hacks and it is post like yours that give me the courage to keep going in the direction of CSS standards.
Good article… I just had to wrestle with this very issue today — I had two identical javascript bits on the same page working differently only in IE! good timing :-)
I hear you Doug. I’ve got an IE bug on my site that I just really don’t even want to deal with. It’s not a show-stopper, but it drives me nuts every time I see it. And don’t even get me started on the
Isn’t several layers of nested floats a hack like tables? Which “semantic” language allows you to float within a float within a float…?
In my humble opinion, if you have to nest floats (maybe second level of nesting is OK, not any more), a table-hack is a better option. Beyond just the jargon and stroking of egos that we “successfully” separated content (XHTML), design (CSS) and behavior (DHTML/javascript), it serves a purpose: to make pages better authored and easier to maintain. BBC, for example, has highly usable, accessible, search engine friendly web page that uses tables for layout.
Da Warriah: Shaun Inman used the “trick” for a Zen Garden submission; not on a “regular” site. Whats wrong with browser sniffing if you anyways want to serve different CSS for different browser? No one will give up a browser because your site doesn’t render in it… they probably will stop visiting your site instead.
I spent some time on webdevelopment forum meant for relative newbies. At times, they consider our attitudes “holier than thou” or “do it this way because God said so” (huh!!). Doesn’t help.
Niket: Thanks for your comment. Nesting floats is not a hack in and of itself. It’s simply a means to an end. See Eric Meyer’s Containing Floats for a nice walk-through.
Note, in the section A Clear Solution, Eric discusses a structural hack for one means of containing floats. But he then reveals another solution to avoid the hack in the following section, Set a Float to Fix a Float, which could have also been titled “Set a Float to Contain a Float”.
We’re not talking about inserting additional elements just so they can fix another element’s float problem. We’re applying another float to a pre-existing parent element to ensure the parent element completely wraps around the floated content inside. That’s just how CSS works. Floated objects don’t force their parent to any certain height, unless the parent is floated too.
Whether building simple or complex layouts, pages have multiple levels of hierarchy and structure. Elements contain other elements, which contain more elements. That’s the nature of HTML and XML. So floating any number of those elements is simply taking advantage of a CSS property for effect.
Four levels of nested floats applied to four nested elements will leave a much cleaner and easier-to-maintain structure than four levels of nested tables and all the resulting markup those tables would require.
And no, nested floats don’t necessarily lead to turtles all the way down. (expression seen recently on kottke.org).
I agree with Alan P. (3) and Keith (12) an article outlining many of the bugs would be nice. I would like to ignore IE after the last couple of weeks, but IE is used by most users who visit our site. We get over a million hits a day and around 30% of them are IE 5.01! This week by mistake (I don’t know if it’s documented) but I found that IE 5.01 will ignore the first rule of a specific type. To fix this problem, I have ended up giving IE 5.01 a throw-away rule.
/* IE 5.01 throw-away rule */
div#content ul li {
display: block;
}
/* then the “real” rule */
div#content ul li {
…
}
/* since I’ve already defined this type of rule I don’t have to use throw-away rules of the same type for different IDs */
div#footer ul li {
…
}
It’s a pain, but it works. I’m having a problem with floats in IE 5.02 MAC. Is there a resource that can help?
BTW: Doug, I feel the frustration too. Unfortunately I believe that we will have to “deal” with IE for a long time.
Since MicroSoft won’t be updating IE until the release their new Operative System (with a new web browser, mind you) we can’t really do much at all other than bug smashing. Or, the Netscape 4.X solution.
A few years ago, most designers was against Netscape 4.X (which only really had problems with invalid HTML (like unclosed tags), mainly because it was too old. In response, many recommended an upgrade and used JavaScript to do so.
Since IE is rapidly becoming the oldest one on the market, it might be time people upgraded again. From IE. I beleive Mozilla, Opera, Firebird and Netscape has provided new versions quite recently, or within the last few months. IE hasn’t and it won’t.
We will either deal with all the bugs or, recommend an upgrade. People won’t like it. Or subtly recommend them to upgrade. If the problem isn’t adressed, the user won’t take notice. Forcing an upgrade is never fun, and even I have avoided to download the lastest Shockwave player, because I don’t want to right now, but we can’t expect users to sit with IE for 3 more years. Then web standards are going nowhere…
I’m surprised that people would develop for 4% (give or take) of the browsers BEFORE developing for the whopper at 96%. I realize we all want everything to work in ALL browsers - amen to that. But come launch time, if there is a bug in Opera that affects literally 0.1% (I’m not making that figure up - based on a major brand redesign I’m doing right now that gets *millions* of hits - Opera is 0.1%) I’d MUCH rather deal with that pre or post launch than something that affects 96% of my visitors.
This can easily get on a “how do you develop” tangent, which we don’t want to do :). But I have found that squashing Gecko and other browser bugs is easier than dealing with IE strangeness.
Doug you said it yourself - IE sometimes defies logic but the other browsers behave much better. It seems then that leaving the bug squashing to the more predictable makes more sense.
Anyway, that is how I am approaching our major redesign right now. NS7 and IE5, 5.5 and 6 while developing, and that’s it. A few sneaks at Opera so far have show some fairly big bugs, but I’ll deal with that when the major work is done.
My .02
Tom
I have to respond to Fredricks post as well. You can’t seriously think you are going to get users to “upgrade” to mozilla, etc etc? That is not going to happen.
Developers like Firebird and Mozilla, and Opera. Hard core users like them. Frankly, that’s about it. That’s why your logs show 5% and less of those users. You aren’t going to get 95% of the population to switch from a browser that is PART of their OS - literally - to some “third party” browser - not en masse, not in any large group.
You might get a person here and there, but that’s it.
We are stuck with IE until M$ decides its time to change. And even then, it looks like that won’t filter into the mainstream until the populace upgrades to Longhorn - an even longer way down the road. I think we are looking at a good 4-5 YEARS before the next version of IE is spread out in the market. Cheery news.
Tom
Hey, on another tack completely I found it much simpler to do my pages as XML and render using XSLT. Not always supported by the other browsers, but it worked real good in IE.
Tom: That’s a rather defeatist perspective, isn’t it?
I don’t see the situation as being that grim.
With IE going stagnate for so long, it just gives more and more time for people to wake up and smell the coffee, or start itching for a change. Progressive-thinking companies have already started switching for security reasons. Word will continue to spread of alternative choices. Dreaming? Maybe. But in this game, awareness of choice is key. The longer that awareness has to grow, the more it will compound.
IE hole A + IE hole B = Worst. Browser. Ever.
Between the lack of features and lack of security in IE a slip in market-share is certainly possible — remember the Netscape! I think now that the mozilla website is comprehensible by those unfamiliar with the phrase “nightly build” its popularity will really take off beyond the WiFi & mocha set, albeit silently.
Of course, as Doug points out, companies are looking at their options, and really, that’s where the war will be won or lost. Again, remember the Netscape. There was a time when Netscape wasn’t free for commercial use, but IE, fresh-faced and an underdog at the time, was free for any use. By the time Netscape was that free, the war was lost. Netscape was so far behind price-wise and quality-wise that its dominance was destroyed; is this beginning to sound familiar?
“Oh you simpleton, it’s bundled with windows — it’s right there!” - you say, and that’s true, that is a clear advantage. However, entire companies run on standard installs, picture an image with Firebird preset as the default browser. IE would still be there, but in a much more limited capacity (due to the highly unlikely occurrence of a user actually going through the trouble of changing the default to use it). In that scenario it certainly seems possible to gain the market-share needed to threaten the IE monopoly. So, it’s not just up to M$, it’s up to IT departments everywhere, and where I come from those creating the images are the ones who pick the software are the ones who use Firebird.
But then, some companies are also sticking stripped-down versions of XP into ATMs these days, so maybe security concerns aren’t such a big deal after all.
Great article. It expresses succinctly what I want to say to people when they catch me swearing at the “heathen box”. I’ll print it and let them read it whilst I continue trying to sort a problem out instead of launching into a rant!
And thanks for that info on floats in one of your comments. It seems to have solved a little problem I was having (and not just in IE either).
I found that my standards-based designs, developed on a Mac, only needed slight adjustments to work fairly well in IE6. Maybe their underlying simplicity helps. I haven’t tested them in IE5/Win but as my site stats show that most visitors are using 6, I don’t think I want to look under that stone. Anyway, does Ford still support the Prefect (an ancient British model)?
As for Netscape 6, I downloaded a build and it was such a faecal mound I gave up on it after a week. Surely there cannot be anyone out there still using it.
Finally, has anyone found IE6 proclaiming JavaScript syntax errors on code that ALL THE OTHER BROWSERS and I accept as valid?
Oh! A little off point but is it only me that finds the colour scheme of your right column makes it very hard to read? :-)#
Half way to the bus home I realized that my equation above was totally inappropriate and far too flammable to have posted — I forgot you all couldn’t see my coy smile when I typed it. It was meant as a joke, albeit, a not so funny one. I don’t honestly think IE is the worst browser ever, it’s a fine browser, just deficient in certain areas. And I’m mindful of the fact that: “…there are almost no objectively wrong choices in this area. There are only trade offs.” Which I would suggest is true of browsers, as well as font size.
Doug,
I’d just like to let you know that you’ve salvaged my sanity—and though I’m not hopeful that I’ll ever fully regain my sanity since the bugs haven’t been squashed on my latest project, this lets me know that I’m in good company and not the only one debugging within the padded, white-walled room of a straitjacket you might call the IE Factor.
The funny thing about all this, when you step back far enough to see “all the turtles all the way down”, is that we’ve come so far since HTML3 (or even 1.0) in so little time, that I can imagine in 3-5 years this kind of discussion about that “cute quirkiness” of IE will bring back a kind of nostalgia for times when developing for the web meant primarily WEB BROWSERS… I mean, M$ wants its operating system in cell phones and video games and now they’re talking about taking over RFID chips! If their flagship product is this bad, standards folks in OTHER FIELDS better start ganging up on M$ now before they monopolize yet another growing technology-delivery tool and muck it up as bad as they have with IE!
Re: Dave Shea’s comments on design
I too have started designing first for Mozilla Firebird, then modifying the CSS to support IE. However I haven’t had the good fortune Dave has had with IE/Mac. I just worked on a design and ran into terrible problems because of inheritance of clear in child elements. It took me about an hour to make IE/Win to work and after three days with IE/Mac, I’m about ready to give up on 0.2% of our users because I just can’t get it to work when I get to the footer.
BTW, if you go to my personal site, please accept my apologies for the fact that my site’s CSS does not render in anything but IE. It uses a Domino database for the BLOG software and it currently doesn’t use the correct MIME types, so browsers other than IE don’t see the CSS. It worked when the base files where on my local disk. That’s what I get for free. :) They’re working on it.
Let me tell you guys why you are wrong when you criticize IE or actually bash IE and Microsoft. Cause you only think that IE is just for web stuff, web sites. Well that’s true, it is for web, but not just your web, it is also used by applications, web applications etc…
People will attack me, just for saying this, without understanding what the hell I am talking about, but for those who are smart and really want to understand the reasoning behind Microsoft’s decisions, follow me.
I am a programmer who uses web for really complex dhtml stuff as well as backend applications. Because from time to time, I use linux, not very often these days actually but I might in the future, I decided to support mozilla from day one. So everything I do has to work both in IE and mozilla. I didn’t really go and read the w3c stuff deeply to understand every detail before starting the job, but eventually I ended up learning every detail quite well. I learned all of these during the my experience with mozilla. What I realized is that, w3c shouldn’t be behind these standards, cause they make terrible non-intuitive decisions. When you want to learn the height of a particular “component” you want to know the damn height of that component. You don’t want to think about the margins, the border, the padding etc… That complicates things for you, cause that’s not how you work in other platforms, awt, java, wxwindows, windows forms, etc… So people who think they are smart when they recommend the standards are not smart at all, cause they are not working on really complex applications. Their pages are extremely simple, their back-end apps are also simple. So the way I feel is that, there is no way Microsoft can follow these incapable people. I am not happy that Microsoft goes in its own way and others goes in its own way. But w3c people clearly didn’t listen to application developers’ ideas, and I know that some people with high egos made terrible decisions, like white space in xhtml. Well white space is part of xml, but most of the time you edit xml files for programs using apis. But you write xhtml by hand. It become more and more complicated to be able to test things. So anyway, Microsoft and application developers have no choice but to abandon w3c. We can’t let these incapable people control the future of applications. I don’t like the idea of developing web applications just for Windows, but I don’t see how these w3c people let more capable people move the standards forward for the application development. Especially when they think that they have the power cause there are so many people fighting for them. In the end w3c is the one killing the web. People who just trying to make things work will not follow w3c anymore. They are not moving forward, we need a much better platform for the web, so that application developers can develop really complicated, intuitive interfaces for the web. People are sicking of referring to a component using document.getElementById, that’s not how we work in other gui apis. Better encapsulation, better transparency is needed. We need strong-typed javascript. We need a standard way of including video and animated content on the web, we want to be able to control the animation with simple apis, etc… We also want to be able to produce graphs on the browser, right in the client.
Well, Jim, I’m afraid that you didn’t manage to explain to me why criticizing bugs in IE is wrong. I do understand some of what you’re saying (I’m also a programmer), but I disagree with a lot of it.
You accuse the W3C of making non-intuitive decisions, and use the content/box size model as an example. If you take a step back, a deep breath, and think about it, you’ll see that the content size model actually makes more sense in a generic perspective. How else would you specify the size of a container that would wrap around a 320x240px image, with 0.5em padding and a 1px border? From a graphics design perspective, the box size model can sometimes be more useful, but it’s easier to emulate that than the other way around. Besides: a) both models will probably be available in CSS3, and b) even Microsoft realized the error of their ways and fixed their box model bug in IE6.
Microsoft claims to support certain standards in their browser (HTML, CSS, …), when in fact they don’t. I think that’s a good enough reason to criticize them. Maybe IE7 will have better standards support, but then again … maybe it won’t. Maybe it will just include another bunch of MS-specific extensions that will tie their customers even more firmly to the company bandwagon?
/Tommy
in re Jim:
I am a programmer who uses web for really complex dhtml stuff as well as backend applications.
DHTML for ‘backend apps’? You man intranet/extranet apps or some such, no? When I’ve heard (and used) the term ‘backend’ it’s typically referred to the model and controller portions of an MVC (Model View Controller) design pattern—bits for which DHTML is useless.
When you want to learn the height of a particular “component” you want to know the damn height of that component. You don’t want to think about the margins, the border, the padding etc… [sic]
True enough, and I also preferred Microsoft’s original box model to the W3C’s insofar as it included padding and border in the
widthattribute.That’s only one aspect of the difference between Microsoft’s CSS implementation and the W3C recommendation, however. CSS 2.1 includes a number of very useful properties (
min-width,max-width), values (position: fixed,background-position: fixedon elements other thanbody), pseudo-classes (:hoveron elements other thana) and selectors (adjacent and sibling) that Microsoft’s implementation does not, to say nothing of other W3C-backed standards that IE doesn’t support such as alpha transparency in PNG. I would rather deal with a sub-optimalwidthproperty and have those items than not.Moreover, a key advantage of the W3C recommendations is that while they are not perfect, they are at least open: they are free to implement and can be influenced by anyone (well, anyone who signs up for the appropriate mailing list and/or can afford the membership fee). The W3C, for all it’s warts, is a vendor-neutral body whose participants include a wide range of firms and organizations—including Microsoft. Microsoft is just one software vendor. Be they ever so benevolent, they still must maximize shareholder value, just like every other for-profit corporation in the world. Their interests are not always identical to—and are occasionally in conflict with—those of the rest of the industry. More, they have a responsibility to their shareholders not to put the interests of the industry as a whole ahead of their own. One need only note the many ISVs and VARs have bemoaned their management of the Windows API, and recent issues with their disclosure and licensing per the latest antitrust settlement, to see that Microsoft does, in fact, take their duty to their shareholders quite seriously.
So people who think they are smart when they recommend the standards are not smart at all, cause [sic] they are not working on really complex applications. Their pages are extremely simple, their back-end apps are also simple. So the way I feel is that, there is no way Microsoft can follow these incapable people.
So your argument is something along the lines of “I build high-rise office buildings, you build single-family homes. High-rise office buildings are more complex than single-family homes, therefore your opinion is invalid”?
That’s just absurd on so many levels.
First of all, ‘DHTML’ is marketese for HTML + DOM + CSS + JavaScript. It’s woefully inadequate to describe rich web-based user interfaces because it excludes a whole range of technologies relevant to deploying browser-based apps including Flash, XAML, XUL, SMIL and SVG.
More, you’re imposing a false value judgement. Just as there is a need for both high-rise office buildings and single-family homes (putting aside various environmental and urban planning arguments for simplicity here), there is a need for both complex application-style UIs and simpler document-style UIs. One isn’t more valid (or valuable) than the other; they are simply different fields of endeavor.
As well, just because someone does a simple site does not mean they are incapable of doing a complex one. I’ve done many simple sites because that was what the client needed, not because I was ‘incapable’ of doing anything more complex.
Further, complexity isn’t a virtue in and of itself. Many would argue the opposite, in fact. Complexity is sometimes necessary to achieve a particular set of requirements, but it isn’t of itself a good thing.
More, back-end complexity and front-end complexity are orthoganal. Amazon, eBay, /., The New York Times and the BBC have relatively simple front-ends from a technology standpoint, but their backends are anything but. Lumping the two together is misleading at best.
You also seem to be unaware that the persons most responsible for CSS are, in fact, highly competent in the field of multimedia user interfaces. For example, the author of the very first CSS submission to the W3C, Håkon Wium Lie, was involved in multimedia UI development at MIT in the early ’90s—well before most of the folks posting here had ever seen a web page. You should read the bios of the authors of the CSS recommendations, such as Hakon, Bert Bos, Chris Lilley and Ian Jacobs before claiming they are ‘incapable’. Brushing up on the history of CSS might also be in order.
Finally, you fail to mention that Microsoft contributed as much to CSS as anyone. They are not only a member of the W3C, but also participate in the CSS working group and in fact have a patent on CSS. To claim that Microsoft understands the needs of developers where those responsible for CSS and other W3C recommendations do not is absurd because Microsoft is among those responsible for the W3C recommendations, especially CSS.
With all due regard for your web-based UI development skills, the statement above makes me more suspicious of your competence than of the competence of anyone at the W3C.
I know that some people with high egos made terrible decisions, like white space in xhtml. Well white space is part of xml, but most of the time you edit xml files for programs using apis. But you write xhtml by hand. It become more and more complicated to be able to test things.
To what are you referring, exactly? What is your issue with the handling of white space in HTML/XML?
People are sicking [sic] of referring to a component using document.getElementById, that’s not how we work in other gui apis.
The DOM can be cumbersome, true enough, but you should remember that it isn’t really a GUI API. It’s an API for manipulating documents—namely XML documents. Because it is intended for general document manipulation, rather than strictly for GUI development, it will be more cumbersome in some respects than a specialized GUI language. It is, however, also more powerful insofar as it can be used in a wider range of situations.
We need strong-typed [sic] javascript.
Firstly, that’s an issue to be raised with ECMA International, the maintainer of the JavaScript (properly ECMAScript) standard, not the W3C.
Secondly, it is up to browser manufacturers to implement support for other languages—be they strongly or weakly typed. The W3C DOM is intended to be language-neutral.
Finally, whether JS should be strongly typed or no is really a matter of opinion. Plenty of successful languages (Perl, Python, PHP) use weak typing. Strong vs. weak typing is a long-standing religious war in computer science. Some, such as Python creator Guido van Rossum, think weak typing is an advantage. In any case, the debate isn’t going to be settled here, nor is it really appropriate to this thread.
We need a standard way of including video and animated content on the web
There is a standard way of including multimedia in a web page: the
objecttag. It is serviceable now, though Microsoft and Eolas have peed in the pool, so to speak, with the proprietarycodebaseattribute and frivilous patent, respectively.Controlling multimedia is the province of SMIL. If you want support for something of that sort in the browser, talk to Microsoft.
we want to be able to control the animation with simple apis, etc… [sic]
What would you suggest? I am not the world’s foremost Flash or Director expert, but my experience with those two apps indicates that using ActionScript or Lingo to control animation isn’t particularly more difficult than using ECMAScript + DOM. What the latter lacks boils down to a standard client (precisely the problem other posters are bemoaning) and some convenience methods that could be provided by a custom library as easily as by the core language/object model.
We also want to be able to produce graphs on the browser, right in the client.
You should look at SVG, particularly the RCC component of SVG 1.2. If Microsoft (and Opera, Apple, the Mozilla Foundation, etc.) would get on the stick we’d have just that.
On a related note, given your emphasis on applications you might also be interested in XForms.
Most of what you want is either available or undergoing active development at the W3C. The reason you can’t use it is because browser developers, particularly Microsoft, have been slow to implement the relevant recommendations—which is precisely the point of this thread.
Microsoft isn’t the solution to your problems. In fact, they are creating those problems: they help to author standards, refuse to support them and when developers complain about lack of functionality they offer up a solution which amounts to ‘buy our software’. That isn’t safeguarding the interests of developers or the future of the web; it’s a protection racket.
Re: Tom’s Post
I’m not saying that other web browser will take over the web. But when it’s an issue about old software, the user eventually has to upgrade. This process itself might take 4-5 years before it’s widely spread. But we can’t really expect ourself to design for a 5 year old browser when that day comes. We just can’t. And the solution is A) Force the user to upgrade B) Stick with it. Don’t give a crap about other browser and make things work in IE. I for one vote for A.
However, I remembered the days when I sat with my Pentium II. Internet Explorer was so unstable that I had to use Netscape, because it didn’t crash every five minutes or so. Opera works better for me now, more funtions, mail integrated, hotlinks. IE doesn’t come close, unless I want to go 3rd party.
And there won’t be another version of IE. MicroSofts new web browser will have another nice name. And probably more browser-unique specifications. And probably a whole new set of HTML to go with it.
The Browser War ain’t dead. It’s just getting started. Again.
There is a standard way of including multimedia in a web page: the object tag. It is serviceable now, though Microsoft and Eolas have peed in the pool, so to speak, with the proprietary
codebaseattribute and frivilous patent, respectively. [links omitted]Oops—it isn’t the
codebaseattribute itself that’s whack, it’s MS’s value for it (or perhaps Macromedia’s; dunno): the URI is supposed to point to the same domain as theobjectresides on, but is typically used to point to the plugin page for whatever is being embedded.As well, Moz (and NS6+) barf on the
classidattribute since that value is (for Flash at least) specific to Active-X controls—a proprietary Windows-only technology.So MS has mucked about somewhat with the Active-X thing, but it isn’t all their fault.
My bad.
Now I know what to call that annoying feeling when I can’t do anything in IE correctly. the “IE Factor”.
First of all, I’d like to say: excellent article. I, too, was glad to see that I shouldn’t (still) consider myself an absolute Rookie in this field just because I can’t tackle all IE-problems with ease. Makes me feel a bit more certain of my own skills in this field (even though, sadly, my new site - and so far the only main one that’s made with Standards in mind - is still under construction and not publicly visible :().
Then some comments on the comments:
Tom said:
“(I’m not making that figure up - based on a major brand redesign I’m doing right now that gets *millions* of hits - Opera is 0.1%”
Whoop dee doo. What you fail to realize, it seems to me, is that your site is not the only site on the Internet, and thus it targets a specific audience, and thus gets hits from a specific group of people. Other sites target other groups and get other people as their visitors. Me, for instance, my current (old) site has an average of 25% Mozilla users, 60% non-members (includes spiders like Google) and 15% users with IE. So, between the actual MEMBERS on my site, the real returning visitors, more than half of them use Mozilla. I may not get “millions of hits” each day but I’m just an example. A friend of mine has become just as big a Standards-whore (pardon my french) as I am, and he has actively converted up to ~90% of all his site’s users to using Mozilla/Firebird.
So while it may be true for your site, it does not indefinitely apply all over the internet, and certainly not necessarily as a ‘rule-of-thumb’ for us Standards-crazy webdevelopers. Sure, Google’s Zeitgeist shows that Google itself has been used for about 90% by IE5/IE6 users. But again, each site targets their own audience, and sites like these, SimpleBits, Meyerweb, etc. etc. etc., they all have a target audience that includes a very large share of webdevelopers like myself who care very much about Standards-based webdevelopment, and use a Standards-compliant browser.
This statement:
“That’s why your logs show 5% and less of those users.”
Will undoubtedly be completely off for a site like StopDesign.
Doug said:
“I don’t see the situation as being that grim.
With IE going stagnate for so long, it just gives more and more time for people to wake up and smell the coffee, or start itching for a change. Progressive-thinking companies have already started switching for security reasons. Word will continue to spread of alternative choices. Dreaming? Maybe. But in this game, awareness of choice is key. The longer that awareness has to grow, the more it will compound.”
Something I’ve been thinking about a lot for the past year, year-and-a-half, is how it would be possible to get a firm grip in the market with Standards-compliant browsers.
Certainly everyone here will agree with me when I say that a ‘holier-than-thou’ attitude is unlikely to get many people to switch. Likewise when I say that literally forcing people to use a good browser, lest they get a blank, style-less page like NN4, will not achieve the desired result.
So how do we do it, then?
My vision on that is simple. Don’t fight them. Be on their side.
Of course, you may think “Be on their side? What? Use IE or so???” - but that’s not what I mean. No, instead of trying to convince others actively to switch to a better browser, do it passively: offer explanations on why their browser may not be the wisest choice (Showing them dangerous IE security leaks is always a good option, if only because almost every week a new one will be found ;)), add cool add-ons using MOSe, useful functionality, prettier appearances and the like, and explain that these nifty things are only available in Standards-compliant browsers because they use Modern-day techniques that IE is sadly running behind on, a bit.
Whatever you do, try to avoid - at all times - to give the impression that you Hate IE. If people think, for only a split second, that you might just be an IE-hater, they will shrug it off and generally treat the rest of your explanations and all as “IE-bashing”. “Oh, this guy is just another anti-IE purist or something…”
Getting people to switch works best when they end up thinking “wow, I didn’t know how much cool stuff I could have been enjoying had I not used IE”. That’s also the best way to get them to tell all of their buddies to use a different browser, too.
So my suggestion to all webmasters would be: don’t hesitate to make plenty of use of Dave Shea’s excellent MOSe concept in your site design(s). Add an explanation page with nice, friendly and encouraging - but not actively recommending! - them to try out another browser, and link to that page visibly and plentifully on your site. Refer to it lots. The more people who have such a page, the more people will become aware of this, and the more casual web-visitors will be reached with our message.
Okay, I think I rant too much, but when I visualize something in my mind, I tend to get ‘a bit’ enthusiastic :)
Erp!
“Add an explanation page with nice, friendly and encouraging - but not actively recommending! - them to try out another browser”
That should be:
“Add an explanation page with nice, friendly explanations, and encouraging - but not actively recommending! - them to try out another browser”
My apologies for any confusion that that sentence may cause.
Yes, we can all relate to this. IE is king of the code wranglers. I loathe to think what Longhorn is going to give us.
Doug said (about getting people to upgrade)
“I don’t see the situation as being that grim. With IE going stagnate for so long, it just gives more and more time for people to wake up and smell the coffee, or start itching for a change.”
You see, I WISH that were true. But if you look at what is going on, that doesn’t happen to any *significant* number of people. Windows users don’t seem to want to use anything but IE - other than us geeks and the people we can influence around us personally. But as the market en-masse - the ONLY shift we have seen in literally years is a shift *toward* more IE users, to the point where we are now.
IE is so tied into Windows that it makes it “work” to change it. Your average Joe really doesn’t have much of a motive to do so. And sites “working better” isn’t a motive to Joe. He thinks sites work fine. Heck - you spent hours on end making sure it does.
You could try and force the issue on IE users, but IMO I think it would be *very* unwise to force 98% (or whatever it is) of your users to go download Gecko, etc because you think its “better” (even if it somehow is). Particularly on a site that depends on commerce. A blog - sure.
Frankly, I HOPE I’m wrong. But I think that most likely, I’m correct. Only time will tell. We’ve seen this industry take sharp left turns before … the dot BOMB comes to mind… ;)
Tom
Tom,
I just want to say: if you sit back and be cynical (no offense meant with that, just how you come across to me) about how we’ll never get rid of IE and how all our efforts our futile, then yes I can understand your position.
But, on the other hand, if you put effort into not only making your site be very accessible and standards compliant, but also an incentive for people to switch (without forcing it to them, but doing it in a nice and friendly way as I described 3 comments above), you’ll find that people actually do go the distance to try out Firebird or so, and this will (hopefully) strengthen your faith in this issue.
I’m not sure whether it would, for you, but I’m just saying that the attitude one could take on this entire thing is very important, as it greatly influences and affects your perspective and estimates. :)
Just my $0.02 anyway…
Comments no longer open for this entry.