It's a great question and I'm not quite sure where I stand. In all honesty, I don't check as many old browsers as I should and since Firefox 3 came along, I haven't so much as even looked at two.

My initial feeling with the 'old' versions of 'decent' browsers is that if people are savvy enough to know they should be using a better browser, they are probably most likely to be keen on updating it. It then becomes the issue of people using old 'bad' browsers such as IE which we can target so it doesn't matter much.

I know I could be doing a lot more testing wise, I just haven't gotten around to implementing a decent structure as I just by with current practice and haven't taken the time to improve. So, I think we should care but I don't know how much and I don't know how much I care myself.

We should definitely move on and forget about old browsers.

The problem in the netherlands is mainly the government. their IT systems all still use ie6. and for some reason they refuse to upgrade. this is by far the largest population still using 6. And pretty much the only reason to still develop for the browser here.

But it's a lot easier with conditional comments. Just build for firefox 3, and put a fix-css in place after that.

I dont tend to bother anymore with safari and opera. On my websites they usually have the same amount of users as Amaya.

We as web developers have all the latest, updated browsers.
Everyone has Chrome, FF, Opera, Safari & IE8.

But, rather than IE6 we never test sites on Older browsers.
Why? Because of this: http://www.w3schools.com/browsers/browsers_stats.asp

Still there are people who are on IE5 too, but we never check for them.

I think that everyone who's an avid & dedicated web surfer should have an updated Browser as the older browsers dont have the features which are changing the face of the web.
Slowly, these people we see that websites dont work on their browsers & they will then know that their browsers are old & eventually they will upgrade.

We as the web developing community have the responsibility to update the users on "the benefits of using latest browsers"

@Hayo You are talking about Netherlands friend. In India all the Govt. Agencies & Institues, even private ones are on IE6. And we have a huge population, think how difficult's that for telling them that they should upgrade. I think all of these Agencies are accountable to 90% IE6 use on net :)

I hate playing both sides of an argument, but with a question like "do old browsers exist" I just have to — if we all really wanted to, we could support every version of every browser known to man, on every single darned platform and device possible. The definition of "support" is what people get hung up on, and I'm still surprised by that, considering how long the web standards community has been extolling the virtues of said standards, specifically how even ancient browsers will understand the *content* even if they can't understand the design.

Even though I've publicly stated that folks should stop supporting IE6, that statement of course comes with caveats — personally, I may or may not support IE6 or *any* browser/platform/version in my own projects, and that could depend on the design, the audience, or my general mood the day I make the decision.

For client work, my personal preference in this area won't cloud what I feel is best for the client's audience — they are the ones who matter the most, ultimately.

I just did my first bit of serious HTML/CSS (yup, no "X" at the front of that) for a client in over 6 months, and did my part to make sure it was presentable to a large part in many different browsers. I didn't check FF1 or Safari 2, or a host of other "older" browsers, because for this particular design it wasn't a) contracted and b) necessary. Had the client wanted broader "support" I would have explained why most of the design wouldn't work in those browsers, and given them alternate solutions so at least "older" browsers wouldn't break horribly, but that wasn't part of this particular project. And so it goes.

Would I love Firefox 3.x/Safari 4/IE8/Opera 10 to be the only browsers we need to account for? Yup. Do I mind terribly testing in other browsers? Nope. Will I still say that IE6 should die a horrible death that involves spikes and a deep, dark pit? You betcha.

So, my line in the sand is more like a line per-project, and per-audience — now that I've typed all this out, re-read it, and re-read your article once more, I feel like we might be in need of a base set of HTML(5?) template + stylesheet(s) that do exactly what you suggest: draw a line, provide a basic set of text styles to older browsers, that can be used on every project as a minimum. Sure, everyone could do this for themselves, yet the same could be said for reset stylesheets, and they are easier to use because of Eric's and others being available.

Thoughts?

When I worked at an agency, the browsers we tested for were the ones I've only ended up caring for: Firefox 2 & 3, Internet Explorer 6 & 7 and Safari 3. In that situation though, perhaps budget becomes more of an issue. I could see how it would be hard to justify to a client why they'd need to pay more to test and cater a site for a browser like Opera which typically sees low usage numbers.

I don't think we should ignore those who don't upgrade to the latest and greatest though. As you said, a bad feeling is left when someone might view your work in an older browser and not have the best experience.

I think part of the reluctance – not sure if that’s the best word – to test older browsers is the difficulty of running separate versions of the same browser on a single computer; it can be done, but is often done so in a hackish manner. IE is famed for an inability to run multiple versions, yet – ironically – with programs such as IETester it has become the easiest of the lot.

We definitely need to worry about IE6 on sites with broad appeal; looking at the stats of a such a site recently, I was surprised to discover IE6 still accounted for 23% of visitors. On the same site the total visitors using all versions of FF was slightly lower, 21%.

There is no single answer for which browsers should be tested; the decision needs to be on a site-by-site basis and based on browser statistics. The line in the sand is something that should be defined by the client in discussion with the developer. For each browser that the developer supports, development time and cost increases; the client needs to be made aware of this.

A base style sheet for unsupported browsers is the most useful method, I’m not sure if browser sniffing is the ideal method to achieve this, but it may be the best we have.

You don't have to be a niche blog focused on tech issues to drop IE6. You could be Facebook, 37Signals, MobileMe, or GMail. These are all complex web apps where the cost of supporting IE6 is high - high enough that even their (presumably) hundreds of thousands of IE6 visitors aren't worth supporting. I think that says something.

I think that with browsers such as Firefox 2 we need to let them go. Most likely if someone is using Firefox then they are tech savvy enough to upgrade when it is nessecary.

In my opinion the only old browsers that will ever really need to be considered are IE, simply because that audience isn't always aware of other options.

Maybe the the other browsers we need to watch are Safari? Surely not everyone who uses a Mac know about upgrading or alternative browsers? Although I am sure this is much less of a problem than IE.

while my boss using ie6, I care (:

but I dont thing using it is normal

Our policy has always been to support the current (release, not beta) and previous major versions of the major browsers, something I carried over with me from work in previous agencies. Our stats bear out the notion that most non-IE users tend to keep their browsers up to date. Unfortunately, even though IE8 has shipped, we have to make an exception to our version rule and continue supporting IE6. The numbers just can't be ignored.

We use one set of styles for all browsers, and then conditionally add fixes on top of that for IE7 and IE6 as separate files.

However, recently, we've begun to make a distinction between the definition of "support" for IE6 vs. everybody else. For everybody else, the goal is "as close as possible to pixel-perfect." For IE6, it's just "not obviously broken." IMO that's perfectly reasonable. In the meantime, we try to be proactive with larger clients who are "stuck" on IE6 for whatever reason.

For me, the issue with supporting old browsers boils down to a single question: Am I supporting a browsers "lack of support" for current standards or their "buggy support" for the current standards.

For browsers like Firefox 1 etc, I think most of the issues with broken browsers is due to a lack of css support, so gracefully degrading for this kind of scenario shouldn't "in thoery" be too taxing (realties aside). By this I mean that your not supporting an old browser per-se, but a general "standards gap" that is more common to old browsers.

For browsers like IE6/5.5 (and probably older versions of Firefox/opera to far lesser extent) etc a lot of the problems are due to buggy support which require browser hacks. As these typically browser-specific, it becomes unmaintainable after a time (remembering hacks of ages past, time required to test, testing on browsers that are not available for public download any longer etc). I'd like to hazard a guess whether web developers starting out in 10 years time will have any idea what the double margin bug is, or how to fix it.

Obviously, for the moment, IE6 is an outlier to this pattern, simply because its current user base is still very large and it has to be dealt with. But then, for the purposes of this argument, I dont consider IE6 to be an "old browser" (despite its age) as it's still a popular browser. When its market share drops away to the sub 10% bracket, I'll then consider it an old browser where I have to weigh up the pros/cons of supporting its bugs.

Who uses old browsers?

People in dysfunctional companies and people with really old computers.

If you are making websites for commerce these people don't matter because they don't buy things. If you are making websites to make the world a better place in some small way, these people aren't among a group that can be motivated.

So, even though they may be nice, good people, if your time is valuable, its being wasted catering to that group.

Jonathan, you're visiting places other people have already been at. Go read up on Graded Browser Support.

I think it's just a matter of cost/profit calculation. Supporting an additional browser always carries a cost, likewise, not supporting it also has a cost.

Personally, I check in Chrome (my browser of choice) and Firefox (my boss uses it). But then again, the pages I design are for internal use and are 100% data-driven (statistics, site administration, etc.). It would be an absolute waste of time and money to optimize for any other browsers.

I agree with Dan. Per project, per audience. Working on a site that sees 6 million visitors per month, 10% of our audience is a LARGE amount of revenue online and we can't afford to miss out on that revenue simply because, I, the front-end guy, didn't want to test and fix for "older" browsers. IE6 is 25-30% of our visitors.

BTW, support for older browsers might sound like a good thing, but in reality you're creating huge hurdles you will need to get trough each time you change _anything_ in the design. That alone should be enough of a reason to minimize the number of supported browsers.

Eventually, you have to move on. The newest version of Office uses a new document format by default. This format isn't compatible with older versions of Office.

Yes, you can save your documents in an older, compatible format. Same as you could still create websites compatible with older browsers. But eventually, people will just use the new format and nothing else.

Personally, I don't care what my site looks like in IE3. Worst case scenario, I know the content is still available and someone could simply view source. :) Assuming, of course, the markup is clean and easily readable.

Fantastic article, Jonathan. For my work, I build projects assuming only a small subset of limitations when I design and code, and work to reduce the indiscrepancies closer to the end of a project, targetting a 95% viewability rate.

I think it depends on scope, to be sure- if the budget (and/or audience) is small, the targets are only Safari/FF 2+, IE7+, Opera 9+. If we've got wiggle room, we work backwards into the past and try to harmonize.

I'm sorry that you feel my comment was useless, I was merely trying to point you in the right direction so you wouldn't wander blindly in the night.

As for people not talking about it, it has been up for discussion already. Even Nate Koechley addressed this last month.

What you can do is to monitor the statistics of your own site (or if none exist, simply refer to the public ones at Net Applications, Wikipedia, W3 Schools et al) and do a judgement call of what subset of browsers to support and maybe later expand on this as things develop.

It's a shame that you would have my comment deleted just because you don't agree with what I said. Like said, I was merely trying to help you by advising not to reinvent the wheel. If there's already data on this then why not use it, right?

Some good points here, but let's not forget that we're not just talking about older browsers. This is about new and obscure browsers and devices as well. There are multitudes of ways people are accessing the web now (mobile, obscure browsers, video game platforms, kitchen appliances) that all bring new and quirky behavior to consider. You can bet that these people expect that a website will be accessible to them in some way regardless of the device they use to connect to the internet.

At Filament Group, we've been advocating capabilities testing as a sort of "gatekeeper" between simple and enhanced app experiences. Everyone here is already using good progressive enhancement techniques anyway (right? :) ), so why not make use of that clean division and provide one experience or the other based on a device's basic standards rendering capabilities? Currently I think a lot of developers assume that devices get one or the other, but what they really get is something mashed up and unusable.

My article for A List Apart outlines this approach (http://alistapart.com/articles/testdriven/) and I gave a talk on this yesterday at MIT "Access-Oriented Web Design" - we'll post the slides and video later today.

This isn't a suggestion to stop testing on your most popular browsers (that's important), but rather a complementary alternate approach to consider, because I think this method of turning a shoulder to however our sites look in browsers other than FF2/3, Safari 3, IE 6,7,8, and Opera latest is just not sustainable. And I'm not saying that OUR capabilities test is the way it has to be done, but test-driven P.E. approach provides a sane way of providing some level of support to any user.
</lengthy comment >

btw - @jeff: "view source" does not an accessible website make :P

@scott but wouldn't it be cool if it did? Would be nice if browsers all had the functionality that Firefox has: View > Page Style > No style. You'd know that no matter how tricky we got with our CSS, if someone was on a browser that didn't support it they could easily remove the styles and have a 'nicely' formatted page based on the browsers builtin styles.

@jeff: Sure that would be cool, but how would that help someone who's using a form that just failed in attempt at swapping all its HTML inputs for flashy div-based, js/css/aria-driven widgets.

Turning off page styles will not help that user fill out the form. And even if it did, suggesting that the user would know to turn of CSS or JS and refresh the page is, frankly, expecting too much.

We're doing things now that are not going to work in some browsers and devices (both old and new). I'm suggesting a different way of thinking about support. Support doesn't mean the same look and behave the same across every browser. It could even mean a subset of features depending on capabilities, but that's much better than nothing at all.

It's a methodology for making that division clean in a fairly expected way. If you can support basic JS DOM methods & traversal, css box model, positioning, yada yada, we'll give you a shot at the enhanced page. If not, here's a page that works just fine already.

This isn't about CSS, or JS, but both and how they work or don't work together.

When the client says "what browsers will the site work in?", you can feel secure saying it'll work in most anything, but it'll work better in devices that support "X" features and we're running capabilities tests to make sure those browsers get an enhanced experience.
"Which browsers are those?" the client may say. We'll we know the popular ones are in there, but who knows, maybe others too, and that's great! right?

re: Yahoo's graded browser support: that's a fine system for claiming which browsers your site supports and why, and it works in combination with capabilities testing, but YGBS in itself is just a disclaimer for which browsers you test and support. It's not a methodology for how to carry out those levels of "support". These two approaches aren't at odds with one another.

I think with old user agent strings, to some degree you have to wonder if they are actually human beings or not. I'm definitely not denying there is a population of people that still use old browsers. I often wonder though about what percentage of traffic on the web is actually automated (spambots, spiders, etc).

Consider that for some sites there is a huge difference between google analytics stats versus stats programs that parse log files. Every hit is logged by the web server, while only user agents that support javascript will be logged by analytics. Is there reelly such a large group of people disabling javascript?

@Jonathan: I'm sorry if you took it the wrong way. I wasn't trying to offend you by not sugar-coating my message, I was simply trying to cut to the chase.

As for having a valued experience (and I assume you mean intended rendering) in every browser, I don't think that's a realistic goal. The only thing you can offer that works everywhere is Plain Ol' HTML (Because let's face it, CSS is an enhancement).

And even if I did have a link on how many people UA matching, I don't think it would make much of a difference. IMO it's a matter of How, not Who.

In fact, I'm not even sure if UA matching is the answer. I'd rather just offer the resources (HTML, CSS, JS) up-front and let the browsers sort it out best they can. In the meanwhile I'd do my best supporting a sensible range of browsers (this is where statistics come in).

If you watch Koechley's video on Professional Front End Engineering, he talks about Graded Browser Support quite a bit, and even shows an example of how Yahoo's homepage is served to a C grade browser.

Basically, (if I understand correctly), they just don't serve you CSS if you're C grade. So, they have a filter server side to modify the markup to remove the link/style tags if the user agent matches against a known DB of C grade browsers.

http://ericmiraglia.com/blog/?p=181

There are some good notes in the comments at:
http://us3.php.net/manual/en/function.get-browser.php

I go with the "intended" jQuery support path.

I will support the LATEST RELEASED version (and 1 previous) of every browser with > 1% market share.

Thus right now (April, 2009) my official support list is:
Firefox 3
Firefox 2
Internet Explorer 8
Internet Explorer 7
Safari 3
Opera 9.5, 9.0
Chrome

That said other browsers will work just fine (e.g. Arora, Pogo, Camino, Lunascape) because they are based on Webkit or Gecko.

But as you may have noticed, IE6 is NOT supported at all, nor is Firefox 1 (although it would likely work fine).

I Tried to add a link, but your spam filter kept choking on it. Google "browser life statuses" for some stats

thanks
stanley

@Zach Leatherman: Indeed, that's what I was referring to when I stated that Nate Koechley addressed it last month.

Server-side UA testing only works for browsers you know about. What's to say an "x-grade" browser is capable or not? Should we really assume it always is?

jQuery recently moved to capabilities testing for many of these reasons.

I'm just saying there's no point of adding support for a browser that is generally considered dead and will never ever ever end up doing a request to my site. IMO it makes more sense to target the browsers that matter and that's the approach that works best. Simple business logic, really.

By brittle, do you mean my test cases in particular or the practice in general? I'll take criticism on my own tests - they could certainly be improved. But jQuery 1.3 runs most of the largest sites on the web, and is driven by capabilities testing (no more UA).

UA testing is the approach that has been in use for years - it's nothing new, which may be why it's not being discussed heavily at the moment. The problem is exactly what you said - we can only whitelist those we know about. What about new browsers and devices that are perfectly capable of using your high-end site? What if they're good but not popular?

A whitelisted site is obselete at launch. It's not a forward-proof approach.

"That does mean that browsers whose UA string refers to something else will get a simple experience, but at least they'll have a reliable experience. We *know* what's going to happen instead of *hoping* that it'll work."

I just wanted to pitch in and say that the way Yahoo does it is the opposite. Nate Koechley stated that they are optimistic about the capabilities of the X-Grade browsers and always serve the full experience for these. That means only the browsers who are known not to be able to render things correctly (C-Grade) will get a reduced experience.

More food-for-thought against UA testing:

Do your clients maintain their whitelist as browsers emerge? How do you ensure their content is viewed as intended years from now?

Maybe Yahoo can afford to do this, but it's not practical for most web sites and apps.

Our industry's practice of using UA detection has only prompted devices to find workarounds to "get in" where they aren't really capable.

UA Spoofing preferences come built-in to most popular mobile devices. This isn't some obscure thing that only Opera used to do. :)

Here's an example of the new blackberry Storm's prefs:
http://www.wirelessinfo.com/content/Blackberry-Storm-Cell-Phone-Review/Software.htm

to quote: "The Storm's marketing materials describe the browser as an enhanced one compared to other Blackberry models. It handles WAP and HTML pages easily, though you are often re-directed to mobile versions of some sites automatically when you're trying to get to the full site. It is possible to change the browser's mode so it operates like Internet Explorer or Firefox to avoid this issue. Javascript is disabled by default but can be enabled via the menu. It's not capable of showing Flash or Java elements, though it shows frames and images with no problems at all."

According to comScore.com, there's around 63 million people accessing the web on mobiles regularly. Of those, around 25 million are Blackberry users - and we know that browser is quirky as QuarksXpress.

Shouldn't we be directing our development attention to improving capabilities testing libraries? If they're brittle, let's improve them!

UA detection is a dead end in the long run.

Look, we all have to remember that it's a numbers game, and it's VERY specific to the site that's being built. I'm reading a lot of "I do such and such", but I'm not picking up on much "for scenario A I do this, but for B I do this".

In other words, analyze the conditions of when and where you use a specific set of browsers for the goal, and audience, of the site. There is no magic pill that will apply to all the work we do. There will be cases where we weigh heavier influence on one brand over another.

For example, the sites that I create for my employer are much more legacy-rooted than the browsers I will be targeting for my own site (when I re-launch).

But it's not just about browser stats... it's about general demographics. Who is your audience? What's the average age group of your visitors? What parts of the world are they visiting from? All of these things matter!

It's common-sense really, you do the research, crunch the numbers, and build for your audience.

@snook: But isn't this approach backed by the promise of web standards that we've all already fully endorsed? These capabilities tests to determine a devices handling of standards-based technologies (CSS, JS). If a browser comes out that handles these technologies well - and more - then all the better!

And if a new device comes out that gets say, the box model, wrong in a way we haven't even seen before, they'll be shielded from a layout they can't handle. Keep in mind that we aren't specifically looking for bugs with these tests. We're looking for *proper* handling. It's a different kind of "whitelist" based on capabilities rather than the capabilities that a device "claims" to have (UA string).

And it comes down to a simple acid test of any web standard features that we're about to make use of across an entire site or app. What's the theoretical difference between this and using Object Detection? Even something as simple as floated columns can make for a jarbled mess in many popular mobile devices - and it's easy to use this methodology to prevent that from happening.

I'll upload slides to the FG site in a minute - there are a couple examples of sites that aren't failing in a usable way. Progressive enhancement alone doesn't ensure much of anything.

The browsers you might be UA detecting for are vastly outnumbered by other mobile devices that may or may not be capable. A quick glance at YGBS makes no mention of any OS's beyond the most popular ones - and no mention of mobile...

Lastly, to counter your point. I'd like to see the size of your UA whitelist in 5 years too... :P

"all Opera users put together. <...> In a way, it's like they don't even exist."

Hey we do exist! But thanks to Opera that keeps up to most of standards so it pages rarely look bad in it if they look fine in all other modern brothers.

@Shimon. Exactly. :) And we can easily check if your browser is capable before delivering enhancements, without a laundry list of UA strings to maintain. </broken-record>

There is no way I can give up IE 6 support at this time. Too large of a % is using, and will continue to use it for years to come. IE 8 update/upgrade is great on paper, but in the end just isn't effective.

It really depends on the audience of a site. Typically I officially support the latest versions of major browsers (Firefox, IE, Safari, Opera, Chrome) along with IE6/7. Supporting IE6 is still pretty much a requirement for most sites since the user base is still pretty large due to many companies not upgrading to IE7/8.

At a bare minimum, it should be functional (JavaScript) in every major browser/version since IE6. However, I'm not going to waste hours/days fixing minor visual bugs for old browsers with minimal usage - I've also started taking the approach that IE6 doesn't deserve a first class presentation and isn't guaranteed as such.

Thanks Jonathan, good to hear your thoughts on this stuff. We'll have some good examples to show shortly, so I'll hold off on saying more until then.

Meanshile, we posted the slides mentioned above if you'd like to "take this outside" ;-)
http://www.filamentgroup.com/lab/access_oriented_web_design_building_highly_interactive_web_apps_that_work_f/

The following link is my response/views related to this post:
Drawing the Line with Browser Compatibility

Designing to particular desktop user agents doesn't seem to do too well when the number of mobile devices is increasing so rapidly.

It's like asking about making layouts sized to 1024x768 pixels... you could show stats on current monitor sizes, but miss out on the wider future audience.

If HTML is to be a universal format, it should act like one.

jd/adobe

@Scott Jehl, @snook

Many mobile browsers use screen styles rather than handheld styles - I've put together a page to demonstrate this - almost rendering alternative media types useless for anything other than printing. I presuming manufacturers made a conscious decision based on how developers were implementing handheld styles or, more to the point, weren't implementing handheld styles.

Without guaranteed capability sniffing or UA sniffing, do we continue to ignore this problem or choose the most reliable method at the time of development?

If UA sniffing is the chosen path, development needs to include a process to automatically update the list for the client, otherwise the job is only half done.

Sorry abotu the double post, left out the demonstration link:

http://code.peterwilson.cc/screen-mobile/

I'm not going to lie- I'm an amateur web developer at best, and with all the pros throwing in their two cents, I'm almost positive it is not worth my time to try and deal with this in terms of development.

Instead, let's view this in terms of the government bailouts in America (not trying to get political, just the first thing that came to mind): Companies failed. They made bad choices, and that led them to very poor financial situations. That is how capitalism works. But because they affected the economy so much, they were handed money to get back on their feet. Money other people had to earn, by making good choices.

Now, the way I see it, IE6 users are the failing companies here. They continue to use an outdated, buggy, and downright terrible browser. They're making a bad choice. And the developers are the government. Because instead of telling the IE6 users "Too bad, get a better browser and come back.", they keep bending over backwards to say "It's ok, we'll accept your bad decision and help you make it work." If I could be lazy and have people bend over backwards to help me, I sure as hell would. I have no incentive to do otherwise.

But if developers stopped supporting IE6 altogether- no patches, no fixes, no checks at all- and just let IE6 users get a broken page when they visited the site... There would be a lot less IE6 users around, because people would realise they can't get away with it anymore.

Sometimes, people need to be allowed to fail before they'll learn their lesson.

But the development community will not take this approach, because it will cost them customers and visitors on a short-term basis, and if they're the first to do it, others may not follow.

Developers, as a group, need to draw a line. There is no "per-project" or "per-person" line. If people are expected to abandon IE6, developers can't keep working to let them keep it.

@paddy
I wish is were feasible to just quit IE 6....I'd be the first to do so, but as you said you lose customers. Referencing some stuff I talk about in my response article, it's not always the users fault they are using IE 6 or the reason they don't upgrade is beyond their control.

Many developers can let it be known to their supervisors that IE 6 support should be discontinued, but not all developers can pull the trigger on such decisions. Also, many clients will push for IE 6 support...it's their money all you can do as a developer is advise them and then it's out of your control.

The truth is (in my experience), that no business dealing with web design has the time to fine tune a particular site for 'deprecated' browsers, since we all know that time is money.

I'm a newbie and have to agree to ignore older browsers, chances are the user is old, poor and unable to upgrade their computer, so why would your client want to target them unless they were a computer manufacturer? I only design to IE7, FF and Safari which covers over 75% of the browser market share, that's enough for me. Oh and is there a petition to get rid of IE6 and am sure we'll all sign it :-) (in fact get rid of IE altogether :-)
Cheers all, good blog, Matt.

http://www.design-intellect.co.uk

It's amazing how the debate that began during the browser wars continues to carry on. I think we do have to draw a line in the sand somewhere. To me it comes well after Netscape 1.0, but it does come before IE6. If we write W3C standard compliant code it's not that hard. Some designs may require some tweaking or alternative style sheets for IE6, but if we keep browser compatibility in mind before we keep designing we can sometimes avoid even having to do that.

I like to test my site in as many browsers as possible. But I don't test to ensure that my pages look identical in each. I test to make sure they look fine and perform properly in each.

In this scenario, a page may end up looking slightly different in browser X than in does in Y, but most visitors aren't comparing browsers when reading my pages. They just want to know that the site works. For IE 6 this may mean some tweaks. For Netscape 1.0 it means the site should degrade nicely, so that when the CSS disappears, the content is still rendered in a logical order.

I have to say I was troubled by Matt's comment suggesting IE 6 users are old poor people not worthy of our attention. This bothers me on 2 levels. 1) It's just creepy to think we wouldn't want to support users who might not be able to afford our products at the moment. Usability is meant for all, no matter what their wealth or health status may be. If someone has an interest in my site, I want to make sure they can use it. I don't want to make it a gated community that excludes some in favor of others.

2)It's presumptuous to assume they can't afford something just because they've not upgraded. There are plenty of wealthy people driving old cars, using old computers, etc. by choice and practicality. And there are plenty of people using IE6 because that's the only browser installed at their workplace. Those people surfing the Web during lunch are still potential customers. Potential customer who aren't going to blame their company, who aren't going to blame IE6, but are instead going to blame us or are client for providing a site that doesn't work for them. In the end it behooves us to serve our visitors.

@matt
I'm sorry to say I know plenty of VERY wealthy people who still use IE 6, wealth does not directly correlate to computer knowledge. I agree with Heidi, if you develop good HTML/CSS it is usually just a matter of tweaking to get IE 6 to function properly. Many sites are still showing IE 6 around 20% of their user base....I will not give up on that crowd, but I also won't spend a large amount of time perfecting IE 6.

My position on this one is very straightforward: browsers are free so why should companies around the world spend millions of $ supporting old kit, when people can upgrade for free?

The only people who have a half decent excuse are those still on dial-up. Perhaps someone should start a fund where all the money that would have gone into old browser support goes instead into mailing Firefox CDs free of charge to anyone who asks..

In my opinion, supporting browsers are influenced by the amount of users. One of my clients has over 9 million visitiors a month. even a browser with a percentage of .5 % still represents a large amount of users.

And as it not my decision to make as of which browser people are using, I do my best ( within reason) to support them as best as I can.

Better browsers get a better experience though :)

I agree with David, as browsers are free, there is no excuse for not updating. Anyone still browsing with really old ones will surly be experiencing plenty of sites not looking right - so either they dont have the brains to figure out they need an update OR they just dont use the internet much - in which case they're not ideal target customers for any website.

As web designers it's advisable to make sure websites work in IE6 for now, but another year on forget it - the coding effort won't be worth it.

Really dont think browsing the internet on a mobile is going to take off like the mobile network providers would hope. Maybe for checking your favs like Facebook, but not doing research via Google for products and services, etc where you'll be checking out lots of sites and their pages.

Good post and blog, some good comments too.

Go to Layer>Matting>Remove White Matte (because the outline here is white).