RE: [xml-dev] Microsoft's deeply cynical appealto"standards compliance"

[Joshua Allen <joshuaa@microsoft.com>]

> > I'm inclined to agree with Joshua Allen:  this was probably
nerd-level
> > decision by someone who doesn't see the big picture, and who is
about to
> 
> But even that would still show a culture in which some employees  feel
> free to screw people to win.   I hope the new judge in their
sentencing

I'm not certain that "screw people to win" follows.  Now that the
"clarifications" and "adjustments" have been made [1], I can share my
experience with similar situations. From work with a number of
non-Microsoft customers who are managing high-volume web sites, I have a
feeling that the issue of how far to go in supporting all browsers is a
common thing that IT managers worry about.  Here is the way I think most
sites view the problem:

A. If a site uses even moderate JavaScript and CSS, the site has to
maintain different code for different browsers.  Typical would be one
set of routines for IE5, one for Netscape 4.x, and another for Netscape
6 and IE6 (since IE6 and Netscape 6 *finally* can share most of the same
code).

B. Between IE 5+ and Netscape 4+, you have more than 90% of the browser
market.  To target this 90%, you are probably going to be maintaining
three separate branches of code.  Any IT manager is going to be weighing
the cost of maintaining custom workaround code against the number of
incremental users she will get.  This is not necessarily about standards
-- for example, if Netscape 6 and IE 6 let you use the same non-standard
code to do something, and some browser with 1% market share is the only
one to support the functionality using the correct standards approach,
the IT manager is still going to put more priority on the 90% of users,
even if it means a non-standard implementation.  Taking this idea
further, how about WML/HDML devices?  They represent a pretty huge
number of devices, but are a *tiny* portion of web traffic.  Targeting
these web clients is expensive in terms of learning curve, dev effort,
and test (talk about behavior that differs from device to device).
Making a decision to get to the extra 0.1% of users who might use a WML
browser is probably a more than 100% cost increase.  Most sites don't
bother.

C. Besides the cost of maintaining three separate implementations of the
same functionality, every new browser and platform you support adds
significant testing cost.  IE for Mac and IE for Windows didn't always
behave the same (maybe still don't).

D. There are probably less than 1% of public Internet sites that test
their functionality against all (or even 99%) of the web browser and OS
combinations that their users will be using.  This means that there will
always be certain browser/platform combinations that will have NEVER
BEEN TESTED for a certain site.

E. Depending on the nature of a web site, the possibility that users
could be "muddling along" using a browser that is completely untested
can be very worrisome.  Banking sites, sites that sell expensive items,
etc. can be very paranoid about this.  For example, if the site
developers are relying on some non-standard behavior without realizing
it, and have tested with Netscape and IE and it works, then they feel
comfortable committing to support orders that are placed with Netscape
and IE.  But then suppose a user comes along with a browser that
actually implements the standard *properly* (the bank never tested with
that browser), and the user gets 10x the proper amount deducted from his
bank account.  Obviously this is a contrived scenario, but the point is
that some IT managers will be very paranoid about committing to support
something that they have not explicitly tested, and they will prefer to
reject everything that doesn't match what they designed and tested for,
so as to not take any risks.  Another reason that people get worried
about supporting other platforms is simply for tech support costs.
Quick example would be some site that uses JavaScript to post an order
confirmation.  This is a bad design, but it happens; maybe they did it
because they didn't know any better.  So anyway, they test the site with
the 90% case, and it works in all their test cases.  Then they start
getting phone calls from people who are upset about the order form not
working.  They cannot figure out what the heck is wrong, and churn
through tons of troubleshooting effort and loss of customers before they
realize what is wrong and fix it.

Anyway, I am in no way implying that this path of reasoning had anything
to do with MSN, but am simply saying that these are some common and
fairly innocent reasons why people choose to leave certain browsers
unsupported on high-volume sites.  I also think that there are better
ways to approach the problems than to block arbitrary useragent strings:

* First, site developers can test for browser capabilities using code
that silently attempts "testing" the things the site needs to do.  Using
a useragent string to determine capabilities is horribly unreliable, but
just reliable enough that it makes you think that your site is working
and makes it impossible to figure out why when it breaks ("What?!? You
mean that version X of Browser Y claims to be running on a PC when it is
running on a Macintosh?!?" -- true story).  I have been burned too many
times; never trust the useragent string.  People spoof it, and vendors
screw it up.

* Next, if your site is not tested with certain browsers and you care
about your users' browsing experience, have the site warn them that they
are using an untested configuration.

* If you absolutely can't risk untested behavior, go ahead and try to
control what browsers are used.  Not many places can get away with
this..

So the questions that most IT shops have to balance are:
- How much do I want to spend designing and maintaining this site?
- What percentage of potential web clients do I need to target?
- What are the potential consequences of letting an untested client hit
the site?

[1] http://news.cnet.com/news/0-1005-200-7660935.html