Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > How many browsers must we support?

Thread Tools

How many browsers must we support?

Posts: n/a
The lack of standards with this **** is incredible.

The best thing to do - is test the code for the most common browser which is
IE. Make sure it works there.

If it doesn't work in one of the dozens of other non-standards based
browsers - just put a blurb on your main page

"This site will not work with ......."

Until there are standards it's pointless trying to support everybody
"Richard Cornford" <(E-Mail Removed)> wrote in message
news:cvdr1o$2ao$1$(E-Mail Removed)...
> code_wrong wrote:
>> 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.

Reply With Quote
Ivan Marsh
Posts: n/a
On Tue, 22 Feb 2005 03:55:11 -0500, BG wrote:

> The lack of standards with this **** is incredible.
> The best thing to do - is test the code for the most common browser
> which is IE. Make sure it works there.

Yea, make sure it works in the browser responsible for forking the

> If it doesn't work in one of the dozens of other non-standards based
> browsers - just put a blurb on your main page

IE is the only non-standards browser (only being a somewhat relative term

> "This site will not work with ......."
> Until there are standards it's pointless trying to support everybody

Don't design your scripts around functions that don't work in geko
browsers and your page will work in 90% of browsers.

Life is short, but wide. -KV

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Browsers, browsers! Quo vadis? El Kabong HTML 23 05-13-2007 08:55 PM
Why must and must not be "final" ? NeoGeoSNK Java 25 11-24-2006 02:02 AM
Two Browsers work! Two browsers won't load. Internet game service won't load jimmie Computer Support 1 02-26-2006 08:36 AM
How many browsers on one computer? John Brandt HTML 14 11-27-2004 04:09 PM