How many browsers must we support?

Discussion in 'Javascript' started by code_wrong, Feb 21, 2005.

  1. code_wrong

    code_wrong Guest

    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
    code_wrong, Feb 21, 2005
    #1
    1. Advertising

  2. code_wrong

    Jim Ley Guest

    On Mon, 21 Feb 2005 02:24:31 -0000, "code_wrong" <>
    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.
    Jim Ley, Feb 21, 2005
    #2
    1. Advertising

  3. code_wrong

    Matt Kruse Guest

    Matt Kruse, Feb 21, 2005
    #3
  4. code_wrong

    Jim Ley Guest

    On Sun, 20 Feb 2005 21:15:23 -0600, "Matt Kruse"
    <> 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.
    Jim Ley, Feb 21, 2005
    #4
  5. code_wrong

    code_wrong Guest

    "Jim Ley" <> wrote in message
    news:...
    > On Mon, 21 Feb 2005 02:24:31 -0000, "code_wrong" <>
    > 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?
    code_wrong, Feb 21, 2005
    #5
  6. 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, Feb 21, 2005
    #6
  7. 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.
    Michael Winter, Feb 21, 2005
    #7
  8. code_wrong

    kaeli Guest

    In article <>,
    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
    kaeli, Feb 21, 2005
    #8
  9. JRS: In article <>, dated Mon,
    21 Feb 2005 13:18:09, seen in news:comp.lang.javascript, Stimp
    <> posted :
    >On Mon, 21 Feb 2005 code_wrong <> 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.
    Dr John Stockton, Feb 21, 2005
    #9
  10. 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.
    Richard Cornford, Feb 21, 2005
    #10
  11. code_wrong

    BG Guest

    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" <> wrote in message
    news:cvdr1o$2ao$1$...
    > 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.
    >
    >
    BG, Feb 22, 2005
    #11
  12. code_wrong

    Ivan Marsh Guest

    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
    Ivan Marsh, Feb 25, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Brandt

    How many browsers on one computer?

    John Brandt, Jun 22, 2004, in forum: HTML
    Replies:
    14
    Views:
    927
    Courtney
    Nov 27, 2004
  2. Oli Filth
    Replies:
    24
    Views:
    932
    Toby Inkster
    Jan 6, 2005
  3. R.A.M.
    Replies:
    3
    Views:
    417
    bruce barker \(sqlwork.com\)
    Jun 15, 2006
  4. NeoGeoSNK
    Replies:
    25
    Views:
    921
    NeoGeoSNK
    Nov 24, 2006
  5. El Kabong

    Browsers, browsers! Quo vadis?

    El Kabong, May 11, 2007, in forum: HTML
    Replies:
    23
    Views:
    890
    dorayme
    May 13, 2007
Loading...

Share This Page