By Craig Buckler

5 Reasons Why You Should Not Publish Supported Browser Lists

By Craig Buckler

browser support listOne of the toughest problems desktop developers encounter when moving to the web is cross-browser compatibility. We now have multiple versions of five mainstream browsers and new applications are announced with alarming frequency. It’s easy for novice developers to depend on a cool CSS trick only to find it fails miserably in browser X (I mention no names…)

Companies therefore resort to publishing officially-supported browser lists, i.e. WebFoozle 2.0 works in IE8 and Firefox 3.5 on Windows. Don’t do it! There are several reasons why supported browser lists are a bad idea:

1. Your Application Should Support Every Browser

Web applications should be written for the web — not browsers. You should strive for device-independence rather than targeting specific OS and browser versions. It’s also rare to be confronted by a feature that’s impossible to implement in one browser.

I accept that real world development isn’t that straight-forward, but web standards and progressive enhancement techniques enable you to create applications that work almost everywhere. Even browsers without CSS or JavaScript can be supported if the commercial benefits justify the additional development costs.

2. Browser Support Lists Require Maintenance

It is impossible to test your application on every combination of OS and browser, so your list will be limited to the platforms you’ve tested. It will expand and contract as the system evolves and issues are fixed.

The list will also be out of date as soon as it’s published. You might offer support for Firefox 3.5, but does that mean versions 3.5.1 and 3.5.2 will also work?

3. It Switches Focus to the Browsers You Don’t Support

You may support many browsers but your list also highlights those you’re not supporting. This can result in negative publicity when fanboys question the omission of their favorite browser (even if the application does work).

Larger companies have more worrying concerns. If Microsoft produced a web application which only supported IE, the conspiracy theorists would be quick to point their accusing anti-trust fingers.

4. It Exposes Poor Testing Practices

It’s easier to fix problems during the development phase, so early and frequent cross-browser testing is absolutely essential. Users will question the reliability of your application if you only support two or three mainstream browsers.

5. It Reduces the Number of Clients

Assume that you’ve proudly announced compatibility for Firefox 3.5 on Windows. It may work fine in Firefox 3.5 for Mac and Linux, but would those users bother to try it?

The primary reason companies publish supported browser lists is to reduce the burden of support. However, a well-tested application should not receive a significant number of support calls owing to compatibility problems. In addition, your application needs users — from a commercial perspective and to find the edge-case issues that you could not identify.

Do you publish a list of supported browsers for your application? Has it saved time and costs or caused more problems?

See also: Microsoft Office Online: a Case Against Supported Browser Lists

  • lawrence_evil

    That is crap. We should no longer have to develop for IE6. A website should not require hacks or work arounds for simple tasks.

  • Carl C

    Whilst I somewhat agree with your post, there are often more detailed issues to be dealt which which mean issuing a compatibility list.

    Advances in jQuery, AJAX, CSS3 and the like means that you often need to set ‘internal’ standards. Otherwise, we’d still all be building Table-Driven sites rather than pushing the boundaries of technology and further enhancing the Internet/Web.

    Surely it should be more of a case that we promote to our users the benefits of keeping their browsers latest (security, support, stability etc) rather than just building applications and sites which work in them all.. if that was the case, then we should all just use Netscape 5.5 and IE5.

    The principle of ‘this site only works in xxx’ is, I agree, not something I would subscribe to – but there has to be caveats to this. I work on the principle that sites will work in *most* modern browsers (in terms of functionality), however may be compromised in some older browsers (Form Versus Function).

    We are the supposed professionals in our industry and as such we should be educating our clients to ensure they are benefiting from our knowledge and experience in the industry. That includes advising them on a ‘recommended’ browser to use to enhance their Internet use.

  • tiffany

    I disagree. Yahoo! does just such a thing with its graded browser support list. Publishing a list of supported browsers does not eliminate the need for testing in all major browsers. Publishing a list of supported browsers does not preclude adherence to web standards and best practices.

    What it does is let the user know that if she or he is using an outlier browser (Omniweb, Shiira, etc), things may or may not work as intended. From a pragmatic and practical perspective, I think that’s fair. And it’s no different than hardware or operating system requirements for running desktop software.

  • JdL

    This is complete BS. Craig, this is disgusting. You should be fired as an objective writer.

    1. Your Application Should Support Every Browser.
    This statement is idiocy in a box. Besides the fact that it doesn’t connect with the underlying explanation, it completely misses the point. Innovative web applications strive to do things that are often SPECIFIC to browsers. Google Gears, Flash, JavaScript-intensive stuff (that would otherwise crash IE6 or IE7).

    2. Browser Support Lists Require Maintenance
    What is WRONG with that?

    3. It Switches Focus to the Browsers You Don’t Support
    So I don’t publish a ‘supported browser list.’ And my site breaks completely on IE6, IE 5.5, Safari 2, Chrome 4, or mobile devices. People will say the site doesn’t work instead of trying a different browser. Get a clue. People NEED to be educated, buster.

    4. It Exposes Poor Testing Practices
    Oh really? So saying that I’ve actually tested — thoroughly — my application in a list of browsers shows that I have poor testing practices? Eh? Come again? Idiot.

    5. It Reduces the Number of Clients
    Posting a list of supported browsers does NOT reduce the number of clients. It provides guidance for users to use a different or newer browser to use the site.

    Sitepoint, why do you let CRAP like this get posted? This is far and away the most uneducated BS I’ve seen from Sitepoint — and lately I’ve been seeing quite a bit.

  • bradleyjond

    HAHAHA!! Priceless.

  • anubis

    If Microsoft produced a web application which only supported IE, the conspiracy theorists would be quick to point their accusing anti-trust fingers.

    erm… this is what they have always been doing, with the notable exception of their sites.

  • Carlo

    I totally agree with JdL. I always give a supported, “tested” browser list, that doesn’t mean my site doesn’t work with XY if it’s not on the list, just that it’s not assured it will work if that browser behaves differently from the others.
    Also I always specifically list the main old browsers the site don’t support, for example IE 5.5 (IE 6 in the next months), Netscape 8, Firefox 1. I also explain that browsers must be updated for security reasons and provide links to download them.

    If we don’t cut off old browsers we won’t support the newer technologies out there. I can accept a user coming with a two years old browser – well, I’ll punch him but I still let him in :). I can’t accept, and there are no excuses, to use a 8 years old browser like IE6.
    You don’t have privileges to install a programm in /programs, well, get Chrome, it installs into Documents directory and doesn’t require an administrator user. Aren’t able to install? Take 5 minutes and learn how to do it.

    Regarding the new releases, just list supported browsers as: Firefox 3.5 or newer/higher, Opera 9 or newer/higher etc.

  • @randymcmillan

    tell the client upfront you don’t support certain browsers..(or versions)…what happens is when your CSS doesn’t display correctly in browser X, the client blames you…then they assume you’ll fix it….which turns into the clusterf@&k any web dev is familiar with….

    This isn’t revealing poor testing…’s setting correct expectations!!

  • smfoushee

    And here I just dropped support for Netscape 4 (LOL).

    Seriously, I understand the point of the article, and in a perfect world not only would this be practical, but hardly needed pointing out. However, I find that you can still post a psudo “requirements” list without stating browser x is required. Simply post a small message at the top of your site stating something to the fact of “Still browsing the web with Browser X? Try Browser Y for a better experience and more features.”

  • mathieuf

    Another message seen often is, “You are using a browser that may not support all the features of this web site…”. Nicely stated, and I proceed at my own risk.

    Good points, Mr. Buckler. Now, what should we be doing? We should be writing for standards, and pushing all browsers to support standards. Then the issue becomes one of the latest standards or not: Dare I write CSS5 when it still has sporadic browser support? Again, the issue reverts back to my customers, and what browsers they are actually using.

  • SpacePhoenix

    IE6 still has about a 25% share of the browser market and so it can’t be ignored yet if you are trying to maximise your client base.

    If you recommend a user change browser chances are they will not bother with your site and just move on, they will not bother changing browser (often if they are in a corporate or educational environment, they won’t be able to change browser).

  • Jaffa The Cake

    Adding to the crowd…

    At the BBC we have a published list of supported browsers. This list, like Yahoo’s, covers more browsers than some developers would naturally test in.

    A list like this means our developers know what they need to thoroughly test in. The list also provides a black-and-white contract for external companies that create BBC sites. If a contractor delivers a site that doesn’t work in Opera, they need to fix it, as Opera support is in the standard that they agreed to.

    If we simply told staff to “support all browsers”, they’d most likely be pragmatic and run tests to see which browsers people were using & support those. But having all of our web teams doing this independently would be a massive waste of public money. So, it makes sense to centralise this research and publish a support list from it.

  • Jasconius

    Completely wishy-washy standardista fodder. This article places idealism ahead of practicality.

  • Anonymous

    What? Linux does not have even the needed fonts. Until CSS3 comes out and all major >used< browsers support it, its not possible to say “I’m developing for the web”.

  • ricktheartist

    The philosophy behind this article is sound and in a perfect world, everything would just work. But the statements are too vague for the real world. “Support every browser?” That statement should at least be qualified with some limitation – “Let’s go see if my site works on NCSA Mosaic – I have a Windows 3.11 machine around here somewhere.” – hogwash!

    My company site does have a supported browser list, but I do not publish an OS with it. I just list the browser and minimum version (as a one man show, I have limited access to multiple os’s and so I rely on the browsers of the same version to function reasonably close across multiple os – I have so far not found any significant difference between Safari on Windows an Safari on OSX). We are also in process of phasing out support for IE6 – I am so thrilled – and I have YouTube to thank for that!

  • ghendry

    Wow. I am surprised by the vitriol in many of these comments. Are graceful degradation and progressive enhancement not used by any of the commenters to handle the less capable browsers?

  • W2ttsy

    I have managed to catch edge cases and site failures through the use of a “report error” link in one of my applications. If a user notes that there is an issue with the site or that something doesn’t work properly, then they simply click the “report error” link and fill out a few brief details. Behind the scenes i capture HTTP and UA information so that i can work out what platform/browser is being used, what page the error was on and so forth. There is also a similar link included when a website error is thrown during some operation (session time out, transaction failed, etc). Together, with logs and JIRA integration, its pretty hard to get stuck chasing a bug.

    It pretty much just follows the look and feel of a “send error report” dialogue that you’d get in OS X or Windows. In fact i got the idea when IE kept crashing on me one time. This sort of proactive support has culled the amount of calls our support line gets by over 60%.

    I might consider sticking a browser checklist in one of the help articles in the application’s knowledge base. We are already detecting lack of JS and IE6 users and displaying dismissible support messages that indicate reduced functionality may occur.

  • primat

    The more we support older browsers, the longer they stick around. Put your foot down and fight the power! Ok, I know that’s not possible since the client will be putting the food on your table. Bottom line is, web applications shouldn’t support all browsers, web applications should adhere to the standards. And browsers too for that matter.

  • ravi_k47

    this is not true, browser list is published so that the user will get the for “best results”. there is need to be published.
    will u ask for a requirement before buying a software? i hope so. simple as that.

  • I’m going to join in and disagree with you as well Craig.

    Consider the following:

    Your favourite game publisher releases a new game, it doesn’t say what Operating System it supports so you assume (since you use Windows) that it will work on your PC, you buy it, take it home, try to play it, and find yourself staring at a BSOD.

    If I use a website, and pay a fee to use a service on that website for example, I expect there to be a list of supported browsers. I expect this list to be there so I can see if my browser is supported, and if it isn’t, then I’ll know to switch to one that is if I am having issues with the site.

    A point raised by Jdl:

    4. It Exposes Poor Testing Practices
    Oh really? So saying that I’ve actually tested — thoroughly — my application in a list of browsers shows that I have poor testing practices? Eh? Come again? Idiot.

    Agreed – all this testing we do makes sure we know what browsers our products are compatible with. We share that information with clients and consumers so that they are aware that issues on a web application might be because they are using an unsupported browser.

  • Ives

    1. Your Application Should Support Every Browser
    – BullS***. Not even miraculous MS can support IE6 and IE8 in a single codebase (so why should we? just because you said so?) which is why they invented the rendering engine switcher in their browsers called a “compatibility mode” (a euphemism for “we screwed up.”) IE8 is the second incarnation of said.

    2. Browser Support Lists Require Maintenance
    – And web-sites don’t?

    3. It Switches Focus to the Browsers You Don’t Support
    – Brilliant: Upgrade your freeking lazy ass and get off IE6 already.

    4. It Exposes Poor Testing Practices
    – No, it reduces development time by focussing on browsers that CAN, not hacking and coding alternates for browsers that CAN’T.

    5. It Reduces the Number of Clients
    – Correction, that’s incomplete: “It reduces the number of clients stuck in the past by kicking their butt into the today-show.”

  • Wow – some strong opinions here. I’d like to clear up a few matters…

    First, I’m referring to completed web applications for end users. Of course YUI should have a browser support list – it’s a set of client side components for developers.

    It is possible and desirable to support every browser. IE6? Pah – I’m talking about a device that supports HTML4.01, no CSS and no JavaScript (perhaps Lynx or a screen reader).

    Progressive enhancement allows you to support a base level of technology. How far you take that depends on your business, budget, client base, and accessibility policies. Government departments generally go further than most.

    That is not to say every device behaves identically. A user with JavaScript can have a richer experience. A user with Flash might see a video rather than a transcript. A user with Google Gears can be offered offline storage. However, the base functionality can still work … if you want it to.

    (I think I need to write an article about progressive enhancement…)

    Just because you support older browsers, it doesn’t mean that you cannot promote the benefits of upgrading. If someone becomes dependent on your application, they may be encouraged to upgrade because of the better facilities. That’s unlikely to happen if they never use your app in the first place.

    The fact remains that many web applications quote support for two or three of the top five browsers. Why? Are Opera, Chrome or Safari not good enough? The reason they are not supported is the cost — even though adding support after the app’s been released is far more expensive.

    It’s a similar situation for IE6. Are you really dropping support for the noble cause of persuading users to upgrade? Or is it because it’ll make your life a easier? Are your clients prepared to lose 15-25% of their customers? IE6 users can be offered a lesser experience and be shown upgrade advice; that’s far better than purposely making your app incompatible or banning them altogether.

  • Wait… let’s clear up the definition of “supported browsers”. For me, that’s defined as “The browsers I, as a developer, test in and in which the application is expected to work OK with the browser’s default settings. If an issue is found in a supported browser, it must be fixed, or at least, a cut out (but usable enough) experience must be offered”. In contrast, “unsupported browsers” refers to “The browsers I, as a developer, don’t test in and in which the application is not cared after (regardless of settings). If a bug is found in an unsupported browser, it may be fixed, but only if it won’t impact supported browsers”.

    This is not to say a site doesn’t work in browser X. It only goes to say that you may (not necessarily that you will) experience issues if you use it.

    IE6? Pah – I’m talking about a device that supports HTML4.01, no CSS and no JavaScript (perhaps Lynx or a screen reader).

    Now there lies the misunderstanding – browsers rarely have HTML issues, and if they do, they’re easy to work around. It’s CSS and JavaScript where the issues lie, and why we need “supported browsers” list. I code my pages so that they work fine without JavaScript, and without CSS (and if your point was THAT, then fine…), but if the browser has partial and/or buggy CSS and JavaScript support (and when you think about it, that’s the case with all browsers; some more than others), there isn’t always a way to shape up the site accordingly. Therefore, problems with browsers in these regards are inevitable. It is because of them that supported browsers lists are also basically a must.

  • Unfortunately Craig, progressive enhancement as a premise is basically dead – suffocated by the Web 2.0 bubble, and finally dispatched by well-meaning but ultimately self-defeating technologies like ARIA.

    I agree with you, but you have you know you’re pissing in the wind.

  • @brothercake
    I’m not quite as cynical yet! I still think there’s a place for progressive enhancement but, unfortunately, few developers practise it in their excitement to implement Ajax widgets.

    ARIA – who knows what will become of that. Support is patchy, although HTML5 may change things. Even so, we’re several years away…

    It’s impossible to test all browsers, and would there be any point testing IE3 on Windows 3.1 or any other rarely-used browser?

    My point is: you should be testing the 5 mainstream browsers (plus IE6 and 7) unless you have an unusual market. Do that and the problems can be fixed at the start. Your app may not be perfect in every browser, but it’s still functional. 99.9% of users won’t have usability problems so you won’t need to publish a supported browser list.

  • issesi sagawa

    I would like to see Craigs head on a plate.

  • Raiden

    It’s not just the poor quality of the content lately, it’s the ridiculous topics in the first place. Get a grip sitepoint. Next it will be how to wash your hands properly after doing some java.

  • @issesi sagawa
    Charming! Is that because you’ve told your boss you can’t possibly implement your app in Browser X?!?

    Thanks for your comments. We appreciate all feedback and welcome article suggestions.

    Now where did I put that SOAP manual…

  • The follow-up article is now available…
    Microsoft Office Online: a Case Against Supported Browser Lists

  • Zach Leatherman

    Craig, I think the word choices you used in the article for point #1 caused a lot of knee-jerk negativity to come your way. It isn’t about support, it’s about baseline task completion. Sure, it may not be pretty in IE6, but can the user still complete their tasks?

    Point #1 is very similar to an article I wrote about Device Independence. Maybe if a few people read a bit more up on the subject, they wouldn’t be so quick to anger.


  • @Zach
    I think the discussion went off at a tangent owing to anti-IE6 sentiment.

    Let’s be clear about IE6: it can be a pain, but the problems are well-documented and surmountable. I understand that it must be tough for developers who have started coding in the past few years, but many just rant about the browser rather than fixing their code. Dropping IE6 support may save development costs and force upgrades but let’s cut the crap: the main beneficiaries are developers — it’ll make our lives easier.

    Of course we should encourage people to upgrade, but IE6 has proved more stubborn than anyone expected. Given some of the comments above, I fear we’re returning to the days of “this works best in BrowserX at WxH resolution”.

    It’s taken many years for standards to be adopted. Cross-browser development is easier than it’s ever been, yet supported browser lists are increasingly common. That’s a shame.

  • madr

    Progressive enhancement and Object detection ftw. That’s all I’ve to say. When the Ajax/web2.0 hype is over progressive enhancement will return again. Until then, I’ll keep building my CSS and JavaScript knowing that some will have a more rich experience and some will get a less rich experience – but the same content.

    It’s all about content and making the content accessible, with some enhancement regarding presentation. Really. Designers and editors crying about IE6 should test their RIA-site in lynx or NN4, or perhaps some old cell phone with an propriate browser. And realise IE6 is far better than they think.

  • Note that Ajax and progressive enhancement aren’t mutually exclusive. You can apply Ajax functionality on top of standard HTML/server-postback code. Hijax techniques are easily achieved.

    But I agree, madr — accessibility and progressive enhancement appear to have been forgotten.

  • Craig S

    Seems like two different arguments going on here to me. Of course we all encourage progressive enhancement, so that even users on mobile devices and the like can use the app.

    I don’t see however why a company should *support* my little javascript-less browser for their complex app. Complex apps are designed to be used by high-end browsers, so why should they take my support calls when I want to complain that the app doesn’t work in an environment it can’t possibly work in?

    Strive for progressive enhancement, but if you’re a professional then know which browser you *support*. There are a gajillion browsers and you can’t test and develop for all of them.

  • JdL

    @Craig Buckler

    I think that many folks, including myself, got offended by your post because it lacks any practical or realistic scope, making it sound more like propaganda rather than enlightening, educational, or inspiring material. You didn’t say anything about HTML 4.01 or CSS or IE6 — what you said was very broad. Coming back and placing limits such as HTML 4.01 really demonstrates that, while you are trying to ‘make amends’ with the community, you’re ultimately going back on what you said. A good Editor-In-Chief usually reviews and would give you exactly the same feedback that the community did before it ever gets published.

    Your best approach would be to print a retraction — and say you learned something. Express the ideal, but you need to also discuss the practical limits.

    You also need to find and use good examples and cases that support your argument for the ideal — Microsoft not being one of them.

    I believe that the concept you are trying to grasp is that web applications should be developed toward web standards, and that the burden of compatibility should be on browsers to support those web standards. This we would all agree with and I’m sure most have in fact taken some part in moving toward.

  • umeshbagalur

    I won’t agree with you, when you are saying applications to be developed for the web and not for the browsers. Then why the browser development companies are not main target as WEB, they develop there own standards? Whoever follows the common standards those are the primary target for the web applications… any thoughts!!!

  • All commentators – please do note that the bloggers here, myself included, are all independent authors. SitePoint does not edit or preview anything that’s published in the blogs in advance – it goes straight from author to page. Just so that’s clear :)

    Craig is, without a doubt, the most contentious of all the authors on sitepoint, and draws more disagreement and complaints than any other. I disagree with a lot of what he says, but I also agree with a lot of what he says as well; either way, I don’t think he needs to apologise for or retract his opinions, whatever they are. No-one should have to do that.

  • willthiswork

    Coming back and placing limits such as HTML 4.01 really demonstrates that, while you are trying to ‘make amends’ with the community, you’re ultimately going back on what you said

    Who entitled you to speak in the name of the “community”? I agree with some of the things he said.

    Your best approach would be to print a retraction — and say you learned something.

    One of the most jerkish statement I have ever read in my life. Evolve man, Buckler made some good points that no one could completely prove wrong.
    That means he brought a hot topic that obviously need to be discussed with open minds.
    In short, he gave food for discussion among professionals, which is the real value of Sitepoint.
    The day when Sitepoint will turn into a twitter-like bullshit, where God only tells what the pundits want to hear I will stop reading Sitepoint.
    Your reaction sucks. You should amend.

  • JdL


    Anybody who would agree with Buckler in this case lacks relevant experience in this industry. You might (and others) might get offended at my saying this, but like you said… “Evolve, man.”

    By the way, anyone with common sense can “prove his points wrong.”

  • Offtopic feedback (for all bloggers here on SitePoint): I guess this is a blogging practice or something like that and kind of understanding what it is for, but I really don’t like every article ending with questions directed to the readers. Most of the time they look stereotypical/automated questions if you know what I mean.

    I’m going to give an extreme example to decribe what I mean: Suppose you write something about Photoshop filters, and you end it with “Are you using Photoshop filters? Do they save time and make your designs look better?”

  • Stevie D

    1. Your Application Should Support Every Browser

    Yes, that’s a nice aim. But we all know that it isn’t feasible. There are plenty of applications that are not guaranteed to work in IE6, Netscape 4 and various other browsers that are considered obsolete or too niche to merit development time.

    Yes, I can write to standards, but that doesn’t mean that browsers will support the code as intended. There could well be some old or esoteric browsers that interpret the code incorrectly, and it isn’t realistic to guarantee 100% support.

    By giving a list of supported browsers, it allows users to see what browsers they can use to definitely access the site. That isn’t to say that other browsers will be blocked, or definitely won’t work, just that there may be problems.

    I often access sites that tell me my browser isn’t supported and so I may not get the perfect browsing experience. In Opera 9.5, that was often true; in 9.6 it was sometimes true; in 10.0 so far it doesn’t seem to be true at all. But I’d rather be told that from the start than be under unrealistic expectations about how well I will be able to get on with a site.

    2. Browser Support Lists Require Maintenance

    It’s easy enough to say that it will work in version x or newer. And you should be testing new versions of mainstream browsers as and when they are released anyway.

    3. It Switches Focus to the Browsers You Don’t Support

    Is that really a problem? Assuming you have included IE, Firefox and Safari (which is the absolute minimum you should be supporting), for the average non-spoddy site, only the tiniest proportion of people will (a) be using a non-listed browser, and (b) care.

    4. It Exposes Poor Testing Practices

    It depends on the nature of your application/website and the nature of your non-support. If you’re making a massive website that’s taking on Amazon, Google and Facebook all at once then it’s OK to expect a colossal testing bank. For a more typical site, that just isn’t realistic. If you are testing in three or four mainstream browsers and it works in all of them without major hacks, the chances are that it will work in any standards-compliant browser. As long as you make it clear that the site “might or might not” work completely and fully in any other browser, rather than that it definitely won’t work or that you have blocked it, I don’t see a problem with that.

    5. It Reduces the Number of Clients

    No more so than producing a website that doesn’t work in some browsers but that doesn’t tell you which ones…

  • Jake

    This is a terrible article and Craig should be embarrassed with his article and subsequent postings. I can only assume Craig does not have sufficient experience in Web Application development to know any better as I’d rather assume inexperience than stupidity.

    Sitepoint, please don’t let this guy write any more articles! I will actually email HQ directly to ask for this write to be silenced.

  • The venom directed towards Craig by a number of people here is appalling. I don’t know if most of you simply misunderstand what Craig is saying, or if you are too ignorant/incompetent/lazy/greedy to have a professional attitude towards your business.

    I hope it’s the former, but in some cases I really believe it’s the latter.

  • I think in many cases it’s mob mentality – once a discussion goes down a particular road, it’s easy for ignorant people to just add more fuel to that, than it is for them to think through the issues themselves.

    Anyway – there’s a basic tenet here, that a web aplication should have two fundamental layers of support: rich content for modern browsers, and plain content for others. Your Netscape 4s of the world clearly fall into the latter category, so it’s no more work to support them than it is to offer the degraded version in the first place.

    The problem is, the majority of applications don’t do this; they’re not built on a framework of progressive enhancement, they’re built to support modern browsers only, and hang the rest. The issue becomes an argument when different people have different ideas about where to draw the line between “modern browser” and “everybody else” when “everybody else” gets nothing at all.

    But if we built our apps with progressive enhancement, arguments like this simply wouldn’t happen.

    This, I’m pretty sure, is the rub of Craig’s argument. And I don’t understand how that basic principle is even up for discussion. I thought we were years past that?

    Except of course I do understand, that we’re not years past it at all. We should be, but we’re not. And the reason we’re not is that it’s easier and cheaper to ignore accessibility and just cater for the mainstream.

  • InyourEye

    Ah yes, the browser support icons. I remember those, back in the “browser war” days. And, I remember when such devices became the visitors’ own dope-o-meter– stigmatizing those sites as out-of-date, low-tech, or whatever is your preferred word for the developer’s lacking wherewithal– after IE’s implementation of JavaScript and, shortly thereafter, the advent of Macromedia Shockwave (i.e. when the disparity in accessible client-side scripting between the two browsers, Netscape and IE, essentially disappeared to the end-user).

    I’m amused that the topic is worthy of discussion, after all this time. Moreover, I find it troubling that so many respondents here are actually in disagreement with the author of the article. I’m afraid that this is an indication of the development community at large having little sense of Standards— not necessarily the so-called web-standards, as disseminated on the ever failing clout of the self-contradicting propagator,– but little sense of why those who produce global mass media tend to reference standards at all.

  • I think some of the readers of this blog need to ask themselves if they would say the things they’ve said in this thread to Craig’s face.

    Don’t forget that this is a community, and the venom that you’re injecting into this comment thread hurts everyone in that community, not just the author. Craig is obviously sensible and thick-skinned enough to view some of your feedback for what it is—unnecessarily nasty to the point of being laughable. Surely you guys can deliver constructive criticism in a more professional manner? Grow up, folks.

    PS. Thanks to the readers in this thread who have delivered useful feedback and tried to reign in the other comments that are off-topic and out of line. You guys are very much appreciated.

  • OldTimer

    Running across this thread way after the fact but hoping a few of you are still watching it (JdL, Stevie D, etc). There is a trend here that really disturbs me, accusations that anyone who would agree with this article show too little experience or similar lack of professional qualifications. Graceful degradation and progressive enhancement are the hallmark of professionalism in web development. More often than not these are concepts that those of us from the wild wild west of the early 90’s introduce to the conversation. Which has me wondering just how many of you questioning the author’s experience are really mere Script Kiddies that never learned to tie your shoes but can velcro them just fine.

Get the latest in Front-end, once a week, for free.