The first part is: know your audience. I just saw a version of this conversation with one of the web developers from The Economist, and his team isn't willing to push away any group that represents more than about 3% of the current audience. Their monthy page count comes to about 5-6 million, so pissing off 3% of the audience translates to roughly 175,000 angry people.

Next, ask yourself how closely does technology X correlate to your customer base? So your website demands Flash, for instance. Fine. That means you're tying yourself to a subset of Macromedia's deployed base. Do you have any numbers to show that your ideal customer is almost certainly in Macromedia's deployed base and almost certainly not outside it?

A sub-question of that is: what business are you really in? Are you trying to sell widgets, or do you make your money pushing Macromedia (Microsoft, Real, etc) products? If you don't get any checks from Macromedia (etc), does it make sense to turn away customers who don't use Macromedia (etc) products?

The next question is: what would the user have to give up if you didn't use technology X? If the answer is "code bloat, longer downloads, higher exposure to pop-under ads, viruses, etc, and a chance to have marketing's 'message' drummed into their eyes and ears," you might not be backing a winner.

The web is a pull-driven medium. It doesn't matter how much you like the site. What matters is how much the users like your site. All the corporate mandates and internal-political wrangling in the world are irrelevant when the user looks at your page. Users don't care about your agenda, they don't follow your corporate marching orders, and they don't have some yutz from department Z sitting over their shoulder saying the site must be this way. They come, they look, they leave. If you're lucky, they'll see something else to look at in the first 10 seconds or so. If not, you'll probably never see them again.

With those ideas in place, the best strategy I've seen is: gentle degradation. Go ahead and add any bells and whistles you want, as long as the site remains functional at a grey-pages-and-click-the-text-link level. That way, the people who don't have technology X can still use the site, but the people who do have technology X can appreciate the extra work you've put in.

the only real good answer to this is to look at the stats for your particular site. if 60% of your audience is browsing with Mosaic 1.0 on VMS, you should probably code your stuff to work with that browser (ie, no css or http 1.1).

ignore the stats people toss around about IE being used by such a huge percentage of the population that you can safely ignore other browsers. most likely those stats were collected by other sites. read your own logs and ignore everyone else. eg, on my site, a good 30% or so of the visitors are using mozilla, way higher than what most other people report seeing.

either way, there's almost no reason not to code to standards. if you keep your markup as logical as possible, keeping all the styling in the stylesheet, and use the @import trick, you can make html+css degrade gracefully in almost every browser. IE5+, mozilla, opera, and any future standards compliant browser can get a nice looking site. NN4 can get a default stylesheet with maybe some very basic color and text styling but no positioning. browsers that don't support CSS get nice lynx-like layouts.

complex table-hacked layouts are the first ones to break anytime a new browser or browser version comes out.

so in general, to bring this back away from webdesign and more on topic, you should code to the standards as much as possible but don't ignore what your users are actually using. if you write code that won't work on the target system, even if it's really the target system's fault for not being compliant with some standard, you're going to get burned. and ignore all statistics that aren't directly gathered from your own userbase.

anders pearson

the only real good answer to this is to look at the stats for your particular site. if 60% of your audience is browsing with Mosaic 1.0 on VMS, you should probably code your stuff to work with that browser (ie, no css or http 1.1).

But how many people are willing to slog through a site that's virtually unreadable on their browser in the first place, to show you who is at your site and who isn't? What do you do if you're building from scratch?

-----------------------
You are what you think.

Building inclusive websites is a little extra work, but it's well worth it. Here are my rules (with grateful thanks to my hero Jacob Nielsen).

• Make your foundation simple and strong
  In web terms that means USE TEXT.
• Include text alternatives for anything that isn't text
  When you include anything other than text for content always include a textual replacement for those who can't see or hear it.
• Usability always wins
  People don't care how cool something looks if that can't figure out how to use it.
• Fail gracefully
  When you have to turn someone away offer and explanation as to why that can't enjoy something and alternatives such as a phone number to call for customer support.
• Build for the customers technology
  That means using templates that deliver custom versions of the content best suited for their browsers. No matter how much extra work it is for you, it's a lot easier that it would be for them to adapt to your technology, and before they do that they will be gone.

()-()
 \"/
  `                                                     

This is really a question of audience (or client).

If I was creating a site for unix users I would look at different set features to focus on (i.e. no frames for lynx, no plugins like flash,...) than if I was creating a site for an advertising firm.

If you want a broad base, but still be able to do cool things like flash, streaming media, frames and (insert current industry buzzword here) you can always use HTTP::BrowserDetect. The capabilities (or ability to use load plugins) of browsers is easily researched.

There is a comprimise. But it may change the way you think about designing sites as well as coding them.

It is quite possible to use a subset of most of the "new" technologies that either:

1. work in all browsers in some fashion or other
2. fail gracefully -- meaning the site can get by with not having the browser be able to render a given technology

It is first important to note that "coding for the latest browsers" does not mean that you have to use 10 pages of javascript,css and the like. Honestly the first step to coding to modern standards won't affect older browsers' ability to render your page one iota. That is using XHTML (either 1.0 or 1.1). You can go so far as to use the strictest version of XHTML, and the older browsers will still render it fine. This would be an example of the first point above: a technology that works in all browsers.

A second example of number one is a technology that works "in some fashion or other" in all browsers. I will caveat and mention that I mean all 4.* and higher browsers, but I can explain how it will do no damage to earlier browsers that do not support it. What I am referring to is a subset of CSS. All 4th gen and higher browsers support some subset of CSS -- wether they agree on how to render it is another matter. But this brings me to my next point.

If you're coding for a large audience that uses such a wide variety of browsers, you should stop caring if your site looks 100% the same in every browser. It won't happen. Not in any practical way. And trying for 100% similarity becomes a maintinence nightmare. If one small change needs to be made to a page, you then have to re-check in every browser -- and probably make small changes for every browser's sake.

So if you take the plunge and commit to the philosophy that it's "ok" to have your sites look a bit different from browser to browser, there are a couple steps you can take to make your transition a success:

• Structure your documents well. Use a header tag ( <h3> for example) to mean "this is a header," not to mean "this is a bit of large, bold text." Use paragraph tags to say "I want a paragraph here" not "I want more space between these lines than a line break will give me." Most importantly, use tables to mean "here's some tabular data" not "ooh, here's my page layout tool."
• If you decide to try CSS positioning for the browsers that can handle it (I can hear cries from certain monks to turn away from the dark side), make sure you order your block elements in such a way as they still make logical sense if you were to read them on-screen in the same order as they're listed in the file. I actually like using lynx to check on this.
• Do your homework. Be aware of what does and doesn't work for different browsers. Acquiring this knowledge will keep you from experiencing suprises, and will probably speed up your productivity. There are quite a few good sites that give easier to understand explanations of those wonderful w3c standards. I also find Westciv's CSS guide to be invaluable.

I'm sure everyone will weigh in on the subject of javascript, but I'll just throw in my opinion on the matter. If you use javascript, make it so it is a convenience to those who have it, but not an inconvenience to those who don't. The subset of compatible javascript between browsers is so small that in 98% of situations where you could use javascript, you probably shouldn't. And there is never a place where you can't get by without it.

So you can code to modern web standards without throwing out older browsers. You may not get to use all the toys in your toolbox, but it does not mean that you need to wallow in 5000 nested tables.

1.2.2 Robustness Principle

At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability IP:1:

"Be liberal in what you accept, and conservative in what you send"

Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, although the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events; mere human malice would never have taken so devious a course!

Adaptability to change must be designed into all levels of Internet host software. As a simple example, consider a protocol specification that contains an enumeration of values for a particular header field -- e.g., a type field, a port number, or an error code; this enumeration must be assumed to be incomplete. Thus, if a protocol specification defines four possible error codes, the software must not break when a fifth code shows up. An undefined code might be logged (see below), but it must not cause a failure.

The second part of the principle is almost as important: software on other hosts may contain deficiencies that make it unwise to exploit legal but obscure protocol features. It is unwise to stray far from the obvious and simple, lest untoward effects result elsewhere. A corollary of this is "watch out for misbehaving hosts"; host software should be prepared, not just to survive other misbehaving hosts, but also to cooperate to limit the amount of disruption such hosts can cause to the shared communication facility.

If your customer wants table hell, then that is what you give him. Of course, you do everything in your power to make it so that someone else gets to worry about laying out the table hell (template toolkit is your friend here...), and if you're that way inclined you try and convince him that he's making a mistake. But if you don't deliver what you are asked for then you are falling down on the job big time.

If you are the customer then do what you think is right. But if you don't look at what you're users are doing be prepared for pissed off users.

Oh yes, I voted your node down I'm afraid. The Web is not The Internet. The Internet is not The Web.

To paraphrase your example, you can choose a toolkit that looks like arse (*cough* Tk *cough*) or go for something that looks lovely but only works on Linux.. Or you could pick something like WxWindows and go insane.

In this case, no compromise is possible.

____________________
Jeremy
I didn't believe in evil until I dated it.

Take for example, the PC.
The IBM Personal Computer was a relatively simple design that has remained pretty much unchanged since its introduction. Now there are parts of the PC design that just show how painfully legacy it is (IRQs tend to be my biggest peeve), but people don't drop it because something new comes out - they do what all computer hackers (Note: hackers, NOT crackers) do - they go around the hiccup to solve the problem.

Computers have not, until recently, been built for "Do this and upgrade every six weeks" (Todays big exception is graphics cards and hard drives, but you get my point).
The internet definately hasn't been like that until certain large companies starting screwing up all the standards to suit their own software, for whatever nefarious reasons they were found guilty of.

Now does this mean that new technologies shouldn't be pursued? Of course not. I like to see pictures when HTTP'ing - of course, Flash completely blows goats on my 233mHz K6, but my perfectly adequate NetScape 4.79 renders 95% of pages JUST FINE thank you.
But, like many above have mentioned, instead of saying "To hell with the other folks, hey, I didn't need that 60% anyway", you should make up your website to work with older browsers (Note: Again as said, it doesn't need to look the same - it just needs to be readable), and then you can pile all your junk on top of that so that the people that can view HyperReactiveHelloKittyPluginX applets can see how good you are at masturbatory webpage juicing.

So that, in my half-page nutshell, is my opinion on redesigning the web so the poor suckers like myself can't use it.

JP,
-- Alexander Widdlemouse undid his bellybutton and his bum dropped off --