How many browsers must we support?

[code_wrong]

Hi, as the subject says
How many browsers must we support?
How many are there exactly?

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"
This being the case .. surely we can cover 95% of the market by coding for
the W3C DOM
I wonder if Opera supports the W3C DOM?

thanks for your thoughts on this
cw

[Jim Ley]

On Mon, 21 Feb 2005 02:24:31 -0000, "code_wrong" <ta*@tac.ouch.co.uk>
wrote:

How many browsers must we support?
All of them
How many are there exactly?
hundreds
This being the case .. surely we can cover 95% of the market by coding for
the W3C DOM

There's absolutely no point using document.layers and no point using
document.all that doesn't mean however that the "W3C DOM is supported"
(whatever that means anyway) The most important situation is no or
unpredictable javascript support at all, these need to be catered for
by falling back gracefully when the js doesn't run - this has the
added benefit of also falling back in those really old browsers.

Jim.

[Matt Kruse]

Jim Ley wrote:

How many browsers must we support?

All of them

That's certainly a debateable point ;)

--
Matt Kruse
http://www.JavascriptToolbox.com

[Jim Ley]

On Sun, 20 Feb 2005 21:15:23 -0600, "Matt Kruse"
<ne********@mattkruse.com> wrote:

Jim Ley wrote:

How many browsers must we support?

All of them

That's certainly a debateable point ;)

Sure, but from my side it depends on what you mean by support,
supporting for me is all the content understandable, navigatable away
not randomly causing script errors to appear. And even that last one
I'm prepared to negotiate for compile time errors alone.

Cheers,

Jim.

[code_wrong]

"Jim Ley" <ji*@jibbering.com> wrote in message
news:42*****************@news.individual.net...

On Mon, 21 Feb 2005 02:24:31 -0000, "code_wrong" <ta*@tac.ouch.co.uk>
wrote:

How many browsers must we support?

All of them

How many are there exactly?

hundreds

This being the case .. surely we can cover 95% of the market by coding for
the W3C DOM

There's absolutely no point using document.layers and no point using
document.all that doesn't mean however that the "W3C DOM is supported"
(whatever that means anyway) The most important situation is no or
unpredictable javascript support at all, these need to be catered for
by falling back gracefully when the js doesn't run - this has the
added benefit of also falling back in those really old browsers.

I don't understand .. there is no point in checking which DOM the browser
supports even though different code will apply to each?

[Stimp]

On Mon, 21 Feb 2005 code_wrong <ta*@tac.ouch.co.uk> wrote:

Hi, as the subject says
How many browsers must we support?

depends how much of the internet population you envisage using your
site.

If it's a major site, then support all browsers.

If only small, make sure you support IE, Netscape and Mozilla (Firefox)

--

"I hear ma train a comin'
.... hear freedom comin"

[Michael Winter]

code_wrong wrote:

[T]here is no point in checking which DOM the browser
supports even though different code will apply to each?

Your "tests" do little in determining what object model is supported
by a particular user agent. For example, IE will evaluate
document.getElementById as true, but it doesn't provide a complete (or
even correct) W3C DOM implementation. Similarly, Opera (among others)
would evaluate document.all as true (if it were allowed to reach that
branch), but it doesn't completely implement Microsoft's proprietary
object model.

You cannot reliably infer the entire model from one brief test. In
fact, you shouldn't necessarily infer support from a number of tests
unless the methods or properties to be used are part of the same
feature set and are closely related. What you should do it test what
you are going to use.

If you want to check that document.getElementsByTagName is supported,
how does evaluating document.getElementById achieve that? The clear
answer is that it doesn't.

See Browser Detecting (and what to do instead)[1] in the FAQ notes for
more information.

Mike
[1]<URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdTop>

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Michael Winter]

code_wrong wrote:

[T]here is no point in checking which DOM the browser
supports even though different code will apply to each?

Your "tests" do little in determining what object model is supported
by a particular user agent. For example, IE will evaluate
document.getElementById as true, but it doesn't provide a complete (or
even correct) W3C DOM implementation. Similarly, Opera (among others)
would evaluate document.all as true (if it were allowed to reach that
branch), but it doesn't completely implement Microsoft's proprietary
object model.

You cannot reliably infer the entire model from one brief test. In
fact, you shouldn't necessarily infer support from a number of tests
unless the methods or properties to be used are part of the same
feature set and are closely related. What you should do is test for
what you are going to use.

If you want to check that document.getElementsByTagName is supported,
how does evaluating document.getElementById achieve that? The clear
answer is that it doesn't.

See Browser Detecting (and what to do instead)[1] in the FAQ notes for
more information.

Mike
[1]<URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdTop>

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[kaeli]

In article <11****************@lotis.uk.clara.net>, ta*@tac.ouch.co.uk
enlightened us with...

I don't understand .. there is no point in checking which DOM the browser
supports even though different code will apply to each?

Not really.
Check for object support, not DOM support.
For example, older versions of Opera will pass a test for
if (document.getElementById)
but they did not properly support
document.getElementById("id").style

If you want your code to not kill browsers you weren't expecting, do a test
before ANY usage of a particular element, function, method, etc.
It may not "work", so to speak, in older browsers, but at least it won't
crash them.
Your site should not DEPEND on script if the goal is to "support" all
browsers ("support" meaning that people can use the site, navigate, etc, not
that it will necessarily look gorgeous in them all).

Example: my cat site uses javascript to do random text in a div. It works in
IE5+, Netscape 6+, Mozilla, Firefox, and Opera 7+. It may work in others. But
for older browsers (or script-disabled) that don't support
document.getElementByID or domElement.innerHTML, they just all see the same
text (no rotation, but no crashing either).

--
--
~kaeli~
The secret of the universe is @*&^^^ NO CARRIER
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Richard Cornford]

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.

[Dr John Stockton]

JRS: In article <sl****************@carbon.redbrick.dcu.ie>, dated Mon,
21 Feb 2005 13:18:09, seen in news:comp.lang.javascript, Stimp
<re*@spumco.com> posted :

On Mon, 21 Feb 2005 code_wrong <ta*@tac.ouch.co.uk> wrote:

Hi, as the subject says
How many browsers must we support?

depends how much of the internet population you envisage using your
site.

If it's a major site, then support all browsers.

If only small, make sure you support IE, Netscape and Mozilla (Firefox)

If the site provides a service to the public, then ensure that you
support the browsers that the disabled use; that is a moral requirement,
and increasingly often a legal one.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[BG]

The lack of standards with this shit 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" <Ri*****@litotes.demon.co.uk> wrote in message
news:cv*******************@news.demon.co.uk...

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.

[Ivan Marsh]

On Tue, 22 Feb 2005 03:55:11 -0500, BG wrote:

The lack of standards with this shit 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
language.
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
here).
"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