code_wrong said:
Hi, as the subject says
How many browsers must we support?
And it is a strangely worded question. It is probably the result of
reading too many technical documents but 'must', to me, implies
compulsion. You don't have to support any web browsers at all. You
could, for example, make up your own mark-up language and serve then as
content from a 'web site' (with suitable content-type headers), if you
really wanted to. And all of the web browsers out there would reliably
fail to display anything (but maybe the option to safe the content to
disk). Obviously that would be an utter waste of time and effort, doing
nobody any good at all, but (given access to s suitable public server)
nobody can stop you.
Compulsion, the definition of what you really must do, comes in the form
of legal contracts and technical specifications. If the contract or
specifications say something must be done then it really must. However,
contracts and specifications are supposed to be given a very literal
interpretation so consider what is really being demanded of a
requirement to support exclusively Windows IE 6 (unqualified), for
example. IE 6 is a user configurable web browsers, various features can
be turned on and off. Authoring for all of the permutations that are
possible on just that one piece of software (including its various
releases, service packs and security patches) is no trivial activity in
itself.
Consider; ActiveX may be enabled or disabled (increasingly disabled
these days), user style sheets may be in use or not, default fonts,
their sizes and color, the dimensions, placement and presence of window
chrome, etc, are all under user control, and ultimately scripting may be
disabled itself. And that is a long way from being an exclusive list of
the possibilities offered by just one browser version on one OS.
Thus, unqualified, a specified requirement to support (only) Windows IE
6 is a requirement to design for a range of possibilities that goes as
far as the total failure of any and all scripts to execute at all. And
so long as the mark-up used avoids too much Microsoft bias and the
scripts feature detect the variability in IE 6's support for them with a
close relationship to the features actually employed, such a design
would have, almost accidentally, also covered the vast majority of other
browsers, because IE 6 not executing scripts should not be significantly
different form any other browser not executing scripts (that is, they
can all just show the underlying HTML).
Of course specifications can be much more heavily qualified. Currently I
am working on a web application, but it is not a public web application,
it is a browser-based alternative client for an existing desktop
client-server application, and is being written to allow the customers
to use their application remotely (from their own servers). The
customers don't want to be subject to any (desktop) OS restrictions and
to achieve that our specification calls for us to support Windows IE 6
and Gecko browsers. We further specify that these browsers will be
javascript capable and (in the case of IE) have ActiveX enabled (because
of the heavy use of web services/SOAP).
The most heavily qualified browser specifications come with Intranet
applications, where it is (sometimes) possible to know exactly what
browsers are in use and exactly how they are configured (at least to the
extent that the administrators elect to impose a specific
configuration).
The appropriateness of more restrictive specifications here is directly
related to the degree to which the use of the end product can be
restricted. Consider someone commissioning a public e-commerce web site,
and naively specifying support of IE browsers (maybe believing the
statistics and assuming that represented an acceptable market share),
and the web developing agents (not being able to design for the possible
permutations of IE) coming back and proposing some more restrictive
criteria, say "default installations/configurations of scrip enabled
IE". That individual may be astute enough to perceive their market share
trickling away with every additional qualification to their
specification.
On the other hand specifications of browsers/versions and configurations
may be considered the minimum standard for a project. Our QA department
needs those criteria so they have something to test against, and without
them it would not be possible to ever declare the project finished. But
I am fairly confident that the end result will actually work on any
(reasonably W3C DOM compliant) script enabled dynamic visual browser
that supports scripting and XMLHTTP requests. Not as a result of any
extra effort to achieve that but just because there was no reason to
write the scripts such that they wouldn't.
How many are there exactly?
More than are known by any individual.
When I run this JavaScript in Firefox and IE6:
function init(){
if(document.getElementById)
alert("W3C DOM Supported");
else if(document.all)
alert("MSIE 4 DOM Supported");
else if(document.layers)
alert("NN 4 DOM Supported");
else
alert("This is a really old browser");
}
Both IE6 and Firefox report "W3C DOM Supported"
As will Opera form about version 5, NetFront/Web Browser, IceBrowser 5+,
Konqueror, Safari and many others, but their W3C support (and
particularly support for dynamic DOM features) varies enormously.
This being the case .. surely we can cover 95% of the
market by coding for the W3C DOM
Maybe (though 5%, if accurate, of the Internet is more than the entire
population of some countries), but we _can_ cover 100% of the market by
designing for the consequences of script failure (clean degradation) and
applying suitable feature detection so our scripts can know when it is
time to degrade. And, as every scriptable browser offers the user the
option of disabling scripting, designing for any one browser (in a
public Internet context) should encompass designing for total script
failure anyway.
I wonder if Opera supports the W3C DOM?
It shouldn't be too difficult to find out, you can download the
Advertising sponsored version of Opera for free (and it isn't even that
big).
thanks for your thoughts on this
To achieve clean degradation the underlying HTML needs to be viable in
itself. It must contain all of the content that the viewer needs access
to, and be capable of being navigated/effectively used. From that
starting point it is possible to layer the most extreme scripted
manipulations of that HTML over the top, and achieve virtually any
desired goal, in a way that enhances the web page without getting in the
way of the viability of the underlying HTML. Achieving this takes
knowledge, experience and (above all) thought.
In practice very little scripting in the wild even comes close to
achieving this; scripts, often as not, become the barrier to the
viability of web pages. And that unfortunate truth promotes an attitude
against scripted web pages.
There are still livings to be made in the creation of such scripts. In
the end it is up to you; you can learn how to accommodate 100% of web
browsers in script design, or you can dismiss the issues and comply only
with what must be done by specification. Though the former makes the
latter much easier, but takes more initial study, and some personal
integrity.
Richard.