Slashdot Mirror
When Should You Stop Support for Software?
hahafaha asks: "I am currently working on a website for a small organization. We (I am not alone in this) have a beta version ready, and are currently testing the site on browsers. We have tried all of the big browsers (Firefox, IE, opera), as well as other browsers, such as lynx, links, w3m and even NetFront. So, when can one decide that they will stop supporting a system. Obviously, going (for example) down to IE 1 is crazy, but is IE 3 crazy? This is not only relevant to web design but to any programming at all. When, for example, can you say that I will *not* support a certain version of Windows. Can you say that now about Windows 98? How about 95?"
Do you use java, javascript, CSS, flash, CGI, etc., or not?
A pure text website with some graphics can support lynx, whereas a flashier site will require more up to date browsers.
--- Grow a pair, liberals... stop letting the Republicans bully you!
Depends on if you consider x% of the interweb population to be valuable to your business.
// file: mice.h
#include "frickin_lasers.h"
For example - Slashdot gave up links support when they added captchas.
That is what I see. When the vendor drops support - and that can range from normal EOL to extended contract based EOL - it is time to stick a fork in it. Sadly, it looks like I get to keep a copy of Solaris 8 running for a few more years....
+++ UGUCAUCGUAUUUCU
Whenever the cost of supporting the customers that comes from supporting those customers, exceeds the benefits of satisfying those customers.
The trick is determining the costs and benefits. But often it is not that hard.
That's a business decision, not your's.
If the company is willing to pay you to support old browsers/OS's because the company is getting something out of the clients with those browsers/OS's, then that is their concern.
If you're looking for a baseline that may be acceptable for customers, you could just use the browser vendor's support matrix. If the vendor doesn't support it (IE 2.0), it'll be difficult for you to support it.
Realistically speaking, it depends on your target audience. It's probably safe to ignore IE5 and older versions of Netscape, because your customers probably can update to newer versions, even on older OS versions.
Among other things, when Microsoft stops supporting it, I stop supporting it. Well, not really. But I stop including Windows 9x workstations in the standard contract, so if you want them supported, each one is an additional charge, and no guarantees are made that problems can be resolved.
Personally, I think that a lot of places upgrade more frequently than necessary, but even I think that anything over 5 years old should have been replaced by now.
Shouldn't the only be stricken as in This is not relevant to web design, but to any other kind of programming?
One of the big advantages of HTML is that it usually scales down nicely. I admit that once you start to rely on Javascript/DHTML/AJAX etc. exclusively you will run into problems, but if you care in any way about search engines being able to crawl your site you will most likely have at least a site map that can be handled by googlebot as well as lynx, links, w3m and any revision of Netscape or IE, however old they are. The pages will possibly look like crap if you rely on advanced CSS like hiding DIVs on demand, but will most likely still be useful. [This wont apply if you just cashed in 10 millions from a VC to build an MS Office clone in JS].
This usually will not require a second development tree, just keeping your design clean and based on standards. I consider this a mayor sales point to management. As a nice extra you will even be able to handle requests from the future mobile web crowd, reaching your side from their smart phone, or even the millions of kids Nicolas Negroponte intends to provide with $100 laptops.
For non-web platforms: as long as it pays.
This may be cruel, but if you invest into older technology that will not generate any new sales, this money cannot be put into offering better service and features or price cuts for the new versions. It will be hard to determine how long something pays, e.g. customers may buy the newer version because they have learned from experience that the product will be supported for a long time, so not supporting W95 might actually be the wrong move. Try to determine how many support request you get from users with older versions and if they are returning customers. Determine the cost (in money and new features that cannot be implemented due to support for the old platform) for keeping the old version on board. If the costs are higher, kick it. Beneath other things you are responsible to stay in business, so you actually can support the current version for your customers.
memomo: free web based language trainer DE-EN-ES-FR-IT
I think the best way of looking at this is with money.
Who are your customers, and what are the demographics of their systems. Windows 98 is still a very prevelant system out there. I am writing this post from a computer that is still running windows 98. The big questions are
How many are you going to loose by not including their system?
how many can you afford to loose?
And how much would it cost to include them?
30% Troll, 50% Underrated, 10% Interesting
Score:5, Troll
I develop websites as well as part of a much larger firm. We stop providing support for older browsers (Like IE 5 and 5.5 Mac) when MS decides to stop supporting them.
:)
.8, and Safari (forget which version).
We will only test on XP, Win2K and win 98, but not 95... (that's just silly
Our browser support goes back to IE 5.5 Win, NS 6, FF
Take the hint from others and you will be able to justify your actions.
The Code Ninja is swift with his tool, precise in his delivery, and deadly accurate in his execution.
I suppose the obvious answer would be "What is the lowest level that you could reasonably expect from your userbase". For a site touting the latest and greatest in web technology, you might be a bit heavier in your requirements than for, say, a site on nutrition.
For regular applications, you might ask yourself what the lowest level is that can reasonably be expected to do what's required. i.e. if you need a gig and a half of RAM for most operations, you might not support Win95 simply because it can't support you RAM-wise.
Then, even if you could do it in '95, would your userbase still be in '95? Really, it just boils down to "what's on the machines of the people you want to serve?"
You are standing in an open server west of a blue house, with a boarded front door. There is an Exchange mailbox here.
There's a formula you can use to help you figure this out.
A) Take the amount of money you're getting IN SALES of older product. Pull a number out your arse to represent the goodwill you get by supporting older products, and add it in.
B) Take the amount of money you're spending TOTAL to support older product. Include salaries, time estimates, etc. Add in the costs of anticipated sales you'd get by people upgrading to the newer version.
Profits=$A-$B;
when Profit is close to or less than zero, you need to drop it.
For some of my specially-crafted, workflow applications, I actually require end users to use Mozilla or Firefox in certain places. In this case, the margins on the sales are high, the number of people using it is fairly limited, and the code being displayed is rather complex, so the cost of getting all the required features working in the legacy IE5/6 browsers was large, while the benefit of supporting doing so was minimal. I don't get asked about supporting IE, but I do get asked lots about Mac.
You want feature N? Get Mozilla. Free download! Works on Windows, Linux, and Mac!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
If I were you, I'd put up a counter and see what browsers are visiting the site, dropping support for browsers that never visit.
The same principle goes for the rest of everything. Have a peek at the statistics, and if no one uses it, then don't support it. It's that simple.
Alternately, don't support it if it's just too hard/impractical to support it. If a minor change would do, then it wouldn't hurt.
I just read that using Opera, you insensitive clod.
Whatever you end up doing, don't block browsers out with the horrid "Sorry, you do not have Internet Explorer 5.0 or better" message. Most of the sites that show that message, I can view just fine if I can manage to get past the browser-blocking "welcome" page. Let the browsers "try" to view the page, even if your "what kind of browser are you?" check thinks it shouldn't be able to. Even if it doesn't display perfectly, the user might still get the information they were looking for.
-- I prefer the term "karma escort."
(total number of users) * (% of users using browser) = # of users who you won't be supporting.
.5% of total market share, but you get my point).
We have a two-tired philosophy: we don't test with browsers that have 5% market share, because we're a small business with limited resources. However, if a user reports a problem in a 5% browser that's easy to fix, we'll fix it. If it's a fundamental issue (lack of CSS support, etc), we'll just say "sorry, can't do it."
If it's not fundamental but not easy to fix, we'll consider the direction that the browser's market share is going in. An IE 4 problem that would take a lot of time to fix is not as important as an Opera problem that will take a lot of time to fix, because any work we do to support IE 4 is less and less valuable every day; Opera work should be worth more or less the same in a year that it is now (yeah yeah, it may gain another
As you get more users, that threshold drops. If you've got a million revenue-generating users, it only takes a fraction of a percentage drop in revenue to justify the resources needed to support an old browser.
Cheers
-b
If I wanted a sig I would have filled in that stupid box.
I see a number of ?s/comments to the effect of 'IS it profitable?'
The aspect of where both you and your users WILL BE in 18 months is not examined and what it would take for continuing support.
Be forward looking, don't be like your 'whatdoyameanweranoutofcopiertoner' manager.
-or-
Bridges being built for tomorrow's traffic, not today's.
Game: Player 'Donald J Trump' now has AI skill level 'experimental'.
When Should You Stop Support for Software?
Whenever I feel like it. GOSH!
The problem with this line of reasoning is that it means supporting browsers (or in the larger view, platforms) which are so old that making your product work with them is a huge security risk.
Supporting older web browsers means allowing 40-bit SSL for "secure" transactions.
Supporting older Microsoft OSes is basically the same in terms of authentication mechanisms, for example.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
There was an article cited on Slash about the horrors of of this from the design side when automakers brought up their system requirements.
So from this viewpoint, I would probably go for the ten year boundary on hardware and software, even though many software makers would like it to be as short as possible.
Heck, Symantec has dropped support for many of their more recent products for a variety of reasons
"It is a greater offense to steal men's labor, than their clothes"
Actually, according to this graph, Safari and Opera are about equal. It would appear many Mac users don't use Safari.
If you can read this sig, you're too close.
Part of the challenge of determining what systems to which you will present lies in weighing the advantages and disadvantages of given software versions with their popularity. As such, I would actually endorse prioritizing support of Windows 95 over Windows 98, since Windows 98 added few if any notable technological advantages over Windows 95 OSR2, feature additions of dubious usability, and was (in my experience) less stable as well. Additionally, developing for Windows 95 always produces compatibility with Windows 98 as a consequence, although the inverse is not always true. "Newer" or "more popular" do not necessarily mean "better" or "more suitable" for testing.
Do you have a captive audience, e.g. are you developing an in-house app for employees of a company with a fixed browser platform? Or are you developing for random users on the net?
In my experience, hardly anyone uses Win95 anymore. Those with ancient hardware typically run 98SE or NT4. With those folks, imho you're within your rights to expect that they at least update to the latest browser version their OS supports. I'm not sure what that is for 98SE and NT4, but I'm guessing IE 4 or 5.
You might also want to test on Safari, unless you're fine with blowing off OSX users.
It depends on your definition of "support". To many web developers, "support" means you deliberately prevent the site from working on unsupported browsers. A slightly more lenient web developers will instead throw up a "hey idiot" message to users that they aren't using an approved browser.
What you need to do is to make the page conformant to standards. Don't use yesterday's revised standard, use something that reasonably supported by a lot of browsers. And use only what you need, because the more odd corners of CSS you decide to use, the fewer browsers the page will render correctly in.
Dish out IE-specific pages to IE, because it whines if it doesn't get them. Then dish out standard HTML/CSS/Javascript to everything else. If you want to be thorough, dish out HTML 3.2 for older browsers.
You will want to *test* the page on a lot of different browsers at a lot of different versions. You should be doing this anyway, without having to ask Slashdot for permission.
Don't blame me, I didn't vote for either of them!
is to code to the most current/secure standards possible for apps that are exposed to general web audiences. for us, that means DOM 2 compliant xhtml 1.0 strict browsers firefox/safari/ie6, etc. clearly, it all depends on your app, and as long as the information layer degrades gracefully for older browsers, you should be good.
Windows CE would be a much better Microsoft operating system for the job, or something completely different - and the software would be much better written in something completely portable. Porting old software and device drivers from MS Win98 would not be a trivial task in a lot of cases (the source code may no longer be possible to obtain in some cases), so there is still a lot of stuff on legacy systems.
This completely depends on your customer base. If 80% of your customer base is Windows 95, then you'd better support that platform. If it's just two percent, and the other 98 percent is Win 98 and Win XP, then it's probably time to rethink that last two percent, especially if continuing to support is holding you back.
That said, think a long time before you drop support, and only do it if continuing to do that support is hurting your company or the product in some way. Customers in that minority that enjoy your products, and especially long time customers who are in that minority, will be pretty vocal about their happiness that you've got a product they can still use. This can help drive further sales.
At some point, you might have to drop support despite the wishes of these customers, but until that time, continue to support 'em as long as you can.
We have a set of potential customers we'd love to be able to support with our products, but the platform vendor bailed on 'em a long time ago. We can't even get the development software for the platform any more. We've had a number of inquiries about that platform, and we know that if we could support those folks, they'd love to have our software, but there's not much we can do.
I'm not trying to attack or troll, but seriously, you can't develop a product to beta stage, and then start questioning whether it should run on hardware/software X or Y.
The correct way to go about any project is to identify the target audience and their technology, and develop accordingly. 12 years of bone-headed decisions have taught me this simple truth.
Never build a house first and then question if the design was right or the tools were chosen correctly - identify what you need in a house first, design it accordingly, and then pick the tools to build it.
If you write standard compliant software / websites / whatever, you don't have to care that much about software versions.
/cdrom && cd /cdrom/slackware /etc/rc.d/rc.S
... because there aren't any reasons not to upgrade. Upgrading is easy, fast, and free.
Also, Software should be easy to upgrade. The point is, sometimes you do have a reason to run old software. Is there a reason not to upgrade your win95 machine to Winxp?, yes, the reason is that it CAN'T be really upgraded, actually, you are reinstalling. My Slackware install has been in my machine since Slack 7. It has been upgraded several times, and now is a slack 10.1.
Each upgrade has been as easy as:
mount
killall5
upgradepkg --install-new */*
That's it, I don't even have to reboot (i allways upgrade my kernel from source).
That's the answer: If your software is not badly designed, upgrading should be easy, and nobody would keep old versions running. I think that noboyd out there is running Slackware 7 anymore, or Redhat 6.2, or 2.0 kernels, or Emacs 19
In Windows, upgrading is complex, takes lots of time, and costs lots of money, and in many cases, it isn't a real upgrade, but a reinstall.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
I say first off code good, w3c-compliant HTML code that any browser should be able to render. Try to keep your website simple, elegant, and to the point. Keep the stuff that requires plugins to view (Java applets, Flash/Shockwave animations, Quicktime movies) to a bare minimum as they will take much longer to load and to tell the truth, a bunch of flashy-blinky stuff gets very annoying very quickly. Also, not everybody will have the plugins to view them (for example there is no Shockwave for Linux) and the others might not want to have to go out and get plugins just to view your site.
And as for testing- look at your logs and see what people use and use those browsers to test. One caveat to that is that lots of browsers can spoof their headers to appear as other ones, except for IE, which neither can nor would ever need to. Commonly, they will appear as IE 6.0 on Windows XP but the browser could actually be anything. So if you see more than the occasional hit by a browser other than IE or Firefox, you kind of have to assume that there is some spoofing going on and should test with those browsers even if the apparent share may only be 1% on your site. I know because I do it- my user agent string usually says Safari 1.2.3 on a Mac PPC or Firefox 1.0 on Windows NT 5.1 (XP) when it is really Konqueror 3.5.0 on i686 Linux. The rendering engine in Konqueror is very similar to the one in Safari so the pages that are for Safari will work with Konqueror just fine. Firefox's GRE is a bit different than Konqueror/Safari KHTML, but it usually works OK. Some web sites tend to have heart attacks when they see the real user agent string and scream "UNSUPPORTED BROWSER!!!" "UNSUPPORTED OS!!!" "DANGER, WILL ROBINSON!!! DANGER!!!" but with a fake one in place, it works perfectly.
Which also leads me to say- don't check browser/OS version for your site unless you are doing junk like using ActiveX that *requires* IE on Windows. It is a pain in the butt and as my user-agent string experience has proven, useless. Just don't do it.
Just "gittin-r-done," day after day.
Part of the problem is that every single site that offers user-agent statistics is in some way biased by its userbase. I really wish Yahoo and/or Google would publish user agent statistics; that would be probably as close to a proper sample of the world as you could get.
Right now, make sure you're turning on user-agent logging for your new site. Yes, the logs do waste some disk space, but they compress to nothing, and there's nothing better than seeing exactly what percentage of your users are using various browsers.
As an example, I made my life much easier when I stopped supporting IE 5.16 on Mac. There's a few very subtle differences between 5.16 and 5.17 when it comes to div's encosing other div's, and 5.16 rendering will break when every other browser is OK. I was able to end this nightmare when I showed my boss that he was the only user in the past six months who had accessed the site with IE 5.16 (which implies, of course, that every 5.16 rendering bug ended up at priority 1.)
And just a reminder that IE 7 is coming, with an, er, interesting collection of fixed bugs, maintained bugs, and removed hacks
In my experience, most users of Opera and Firefox won't fall back to IE if the website appears broken. You've already pissed them off by not working with their preferred browser. If you're not somehow handing bars of gold through the screen, they won't stick around longer than it takes to close the tab.
Batou: Hey, Major... You ever hear of "human rights"? Major: I understand the concept, but I've never seen it in action
As many had said this is your descision the way I see it you have to look at two factors, your customer base and your business plans.
Cuistomer Base
What's your target audience, is it kids, or early 20s (which probably all have newer machines), or are they anyone with low income - potentially elderly/disabld with restricted (library/hand-me-down pc) access. As many have said if you want to serve the blind and disabled you will have to factor that in though you can keep your site modern.
Business Plans
If you guys are planning on rolling out some digital content as a key factor of your business strategy, there is another line for you, some media may not even work on older machines, best to start the PR to let people know wqhat is coming down the road instead of an overnight fiasco as many are not able tro access your new features when they hit.
If you are doing it merely to capture more market atttention maybe you should do a market study by interviewing current and potential clients and seeing what they really need or expect to have in such a site.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
I teach econ at the high school level (besides, it was my major!!). Here's an economic analysis: when the marginal cost of support exceeds the marginal benefit. I know that sounds crazy, but look at it this way. If it require 5 additional hours of programming to support say IE3, and your time is say $50 per hour, then you'd better get at least $250 of benefit from it. If someone is running IE3, that means they're on what, windows 95. If they haven't bought a new computer in 8 + years, then I guess that they aren't going to be buying alot of newer stuff anyways. And if they are content with their poor overall web experience, than accomodating them is probably not worth it. In fact, testing for lynx, et al., is also probably a waste of time. For purely philosophical reasons, adhering to standards is nice, but might not make sense from a practical standpoint. I do my wife's photo web site, and all I use is all CSS2 positioning, no tables, spacer gifs, etc. Why? When she does a shoot, for it to be worth her while someone better spend a few hundred dollars minimum. Checking her stats, 75% of her visitors used IE6 and 16% used Firefox. (6.6% Safari) Do the math. Is it worth it to support 3% of her visitors? If they can't even afford a relatively new computer, $500 maybe, then are they going to spend that on the session and portraits? Now, it depends on also I imagine the audience your addressing. If your site say is for old folks, then maybe they're running their kids old computer and it might have win98/IE4. But overall I'd say just figure out what it's going to cost you, and then what you're going to get from it. Really, if you turn off someone who isn't going to spend anyways, they really weren't a customer.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
I think that it depends entirely on the type of site.
I like to give the example of a local company that was offering some sort of website video streaming software for smaller retail firms. About a year ago, I was forwarded an introductory letter with a demo URL. My default browser, Mozilla, did not load the page properly at all -- I didn't bother to see if it would work in IE or not. Simply put, if you are trying to sell web based software to technical users, you better have the site work in more than just IE.
However, if it's a website of a smaller organization (that isn't technically orientated) that doesn't have the resources to spend on extensive compatibility testing, I will often cut them some slack and try IE.
Here's a crazy idea:
Instead of coding for specfic browsers, write valid code!
That was the whole intent of the web in the first place.
I always find it ridiculous when a website talks about what browsers it "supports." Websites should not be browser-specfic.
Also:
USE AS FEW FEATURES AS POSSIBLE.
I can't count how many times I've seen things that could have been done in simple HTML, done instead in flash, java, javascript, activex, etc. The more different technologies you use, the more you'll get screwed up by subtle glitches in their implementation.
In short, pick a handful of good technologies and implement them properly. Support users by pointing them to software that is not broken.
Life is too short to proofread.
Grandparent post:
Do you use java, javascript, CSS, flash, CGI, etc., or not?
Your post:
No, a flashier website will still work just fine on lynx, if it's done competently.
That's an awful broad statement to make in response to a post that gives five specific examples (some valid, some not). However, grandparent poster did not give sufficient detail, but I'm bored and will give some.
1. Java. I fail to see how a visually oriented java based website will work "just fine" in lynx, regardless of comptence. Let's take a good example of when to use java - I have a number of server software packages that use java based websites to provide system/software monitoring capability, specifically real-time graphing of various things. Lynx cannot provide that. If I'm in text only mode for whatever reason, I'll monitor the servers using text utilities.
2. Javascript. Moving into something I've written recently, I have a nice AJAX based based database front-end. It's meant to allow users on Windows, OS X, or Linux to graphically manipulate the database. It does so very nicely according to all of the users. Lynx cannot do what's required for the application. However, again, if I were trying to work the console, there are text based database front-ends. The key is to use the appropriate tool.
3. CSS. OK, grandparent loses some points on this one, as most things you do with CSS don't affect lynx, in that it simply ignores the CSS and presents the content in plain format.
4. Flash. I'll assume that the flash content is something that would be useful to the viewer and is, per your statement, "done competently." This eliminates sites that use Flash "incompetently" - doing things like using it for naviation and not providing html links to the same content and so on and so forth. This still leaves us with interactive meida, multimedia presentations, online tutorials that simulate applications, and various front-end software as discussed in points 1 and 2 that's also possible to do in flash. Unless you've convinced lynx to download the flash file and hand it off to flashplayer, none of these will work with lynx.
5. CGI. I'll give you this one, as whether a website is using CGI or not really doesn't have much effect on whether a page will work on lynx or not. I suppose maybe the poster was getting at the fact that many of the clever CGI programmers these days also integrate java, javascript, or flash into their applications.
So that gives you two points and grandparent three. I award the belt to him.
Really, what it comes down to is evaluating who will be using your site, what they're doing, and what their needs and expectations are. Most of what grandparent posted about aren't used in a *needed* way on public websites, but are extremely useful when done correctly. You also need to evaluate what portion of your site is reasonable to have higher requirements for. Are you simply presenting information or pushing the envelope into increased user interaction?
Google.com works with lynx, while google maps does not. Part of what google maps presents (directions, things near places) *could* be presented in lynx, but you know, doing so would take a very large amount of effort for virtually no payoff. I don't think google stockholders are loosing too much sleep over the issue.
Similarly, my main website supports and has been tested in IE 5.x for Windows and Mac, IE 6, Mozilla, Firefox, Safari, Opera, Konqueror, Lynx, and Links. It looks virtually identical in all of them, but doing so required some horrible kludges that make the code harder to read and understand.
On the other hand, my web applications (both internal and for public use) support IE 6, Moz/FireFox, and Safari. The code is clean and simple, and works in all three with the exact same code for the most part - there's very little that's coded based on which browser you're using (obviously, the AJAX calls are different). I could spend time devising wa
This was true for me about 5 days ago (and for the most part still is). Then I found a neato extension called ie tab which lets me quickly right click and open a broken page in ie, in a firefox tab. This comes in especially handy for those pesky ActiveX admin control panels (trend micro administration, shoretel phone administration, etc). Also my bank has succesfully broken firefox support very recently, and while I'm confident they will fix it again, in the interim I'm happy to open thier site in an ie tab until the problem is fixed.
If you're not somehow handing bars of gold through the screen, they won't stick around longer than it takes to close the tab.
Wow, thats the first time I ever heard of Windows Updates being refered to as bars of gold. <rant>Seriously, though, thats the only time I use IE anymore. Well, that, and when an application hard codes it as the web browser to open, but I am genernally not pleased with such behavior. Really, folks, how hard can it be to pass a URL to the ShellExecute call and let the OS hand it off to the prefered browser?</rant>
#include <signature.h>
Okay, I see many people are not being a lot of help. They are quoting statistics and all sorts of other things.
To answer your question: Just program in HTML 2. Its what I do. Supports tables, most of the stuff you want to use (except maybe style sheets), works with just about any browser except NCSA Mosaic and Netscape 1. You want flashy graphics? Just do an image map.
Truthfully, most of you users are going to have Netcape 4, Opera, IE4 or something newer. You could probably get away with programing in HTML 4 and hit 98% of your users.
As for developing apps, depends on who your target audience is. I mean, is there really a reason for designing something like Adobe AfterEffects and have it compatable with Windows 95? If you are running 95, it is most likely because you are running 8-10 year old hardware. Do you really want to do video rendering on a first generation Pentium or a 486 that is maxed out at 16 to 32 meg of ram?
Most apps I see now are for 98SE or newer. I know 2 people who are running 98 first edition, and noone running 95.
Many apps that I know of have seperate versions for 2000 and XP, then XP x64 and 2003 Server, then they will have a 9x version for 95, 98, and ME. Of course, those are internet apps. For most consumer apps, scrap anything older than 98SE. I mean, I am sorry, but 98SE is now seven years old. I am not up for the upgrade every year philosophy that Microsoft seems to have, but seven years is kinda pushing it.
The following three alternatives produces different result, and it may also depend on your browser:
<span style="font-size: 10px;">Hello</span><br>
<span style="font-size: 10pt;">Hello</span><br>
<span style="font-size: 10;">Hello (invalid - unit must be used)</span><br>
Validate the CSS you are using through the CSS Validator
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Get a clue. Don't support the browsers. None of them. Don't support the IE series or the Firefox browsers.
Support to a set of standards.
Well, that's the principle. Since 90% of the web surfers (less on tech-savvy sites) use IE, I suppose explicitly supporting the latest version of IE is a good idea. But other than that:
I'm sure there's a lot more that every webdesigner should know, but this is a nice start.
When doing so would not negatively impact your company's bottom line.
You don't have to drop support for any browser. HTML is backwards compatible and you can even write "AJAX" stuff that degrades nicely.
1. Code website that works with no JS and no CSS support. It doesn't have to be pretty (no <font>, just semantic HTML) nor work smootly (just use regular forms).
2. Add styling designed for modern browsers like Firefox, Opera, Safari and hide these stylesheets from junk like Netscape 4 (@import trick).
3. Add CSS hacks for IE (use HTML conditional comments, because IE7 breaks most hacks)
4. Modify document using JS and DOM to add handlers for all dynamic, ajaxy flashy stuff. That's progressive enhancement.
That's funny, only because I'm having a heck of a time getting IE to run on my SuSE Linux 10 machine, the one I use to do all my web surfing.
Until I figure that one out, I with the GP, not going back to sites that are broken in Firefox.
Glonoinha the MebiByte Slayer
In particular, firefox and IE render the 'padding' CSS attribute totally differently. You can write a valid webpage using great coding style and have the width of any given element _undefined_ because you used the padding property of a box. (In Firefox it includes the padding in the width and in IE it adds the padding to the width).
Then, nest these elements inside a fixed width box and watch the fireworks in IE when your page layout collapses because an element is larger than you think.
This is all valid code and it uses as few features as possible. The way around it that I use actually uses _more_ features (I nest the div tags within another div tag and set the margin instead of the padding).
I have a feeling you haven't developed too many web pages in your day. Or at least not too many large projects where you need to use the "features" of CSS to get a properly formatted webpage.
I quit supporting it when the original creators stop supporting it. Windows: 2000 and XP only - no NT, no Win9x - Browsers are the same. If the guys that wrote it give up on it it, far be it from me to continue to support it's arcane functions.
"Straddling the sword of technology..."
I can only assume that not enough moderator points have been allocated to cover them all.