How can i use Javascript to make the way to identify the correct user browser

Discussion in 'Javascript' started by phal, Apr 6, 2006.

  1. phal

    phal Guest


    I think there are many different browsers to browse to the Internet,
    how can I write the javascript to identify different browser and
    display according to the users. Some browser disable the javascript by
    default or by the user, how can i solve this problem if the javascript
    is disable.

    thank you
    phal, Apr 6, 2006
    1. Advertisements

  2. Vast numbers.
    You can look at what browsers support what features and test for those. This
    will leave you in a never ending cycle of updating the code when new
    browsers are released, but - why?
    What is the actual problem? Why do you want to know what browser is being
    David Dorward, Apr 6, 2006
    1. Advertisements

  3. phal

    zhong.zx Guest

    If you adopt X library (
    You can easily get those info by access global variables:

    xVersion - X version string

    As much as possible, object-detection is used instead of
    browser-detection. The following variables are used. They are created
    when you include 'xlib.js'.

    xUA - lowercase user-agent string
    xIE4Up - true if browser is IE 4 or greater
    xIE4 - true if browser is IE 4.x
    xIE5 - true if browser is IE 5.x
    xNN4 - true if browser is Netscape Navigator 4.x
    xOp5or6 - true if browser is Opera 5.x or 6.x
    xOp7 - true if browser is Opera 7.x xMoz - true if browser is Mozilla,
    etc. xMac - true if OS is Mac
    zhong.zx, Apr 7, 2006
  4. That is utter nonsense, and I do not have to read the source code to come
    to that conclusion.

    Thomas 'PointedEars' Lahn, Apr 7, 2006
  5. At least 150, 40+ of which can be scripted.
    You cannot, but you don't need to so not being able to do so is not a
    You want to tell the user which browser they are using? Why, if they
    don't already know they probably couldn't care less.
    All browsers that have the facility to be scripted provide a mechanism
    for turning that facility on and off. They also may provide the user
    with an ability to turn off facilities that scripts may relay upon
    independently, such as IE allowing ActiveX to be turned off
    independently of scripting, taking AJAX dependent scripting with it.
    Ultimately the skills in javascript authoring (once you are intimately
    familiar with the language, the formal DOM and have accumulated some
    experience of many real world browser implementations) relate to solving
    the design problems of writing for the Internet. You can never know
    which browser is on the receiving end, or how it is configured, and if
    you guess and make assumptions you will likely produce an outcome that
    is fatally broken for every user of any browser/configuration that is
    outside of your specific experience (which, given 150+ browsers, will
    not be an uncommon outcome).

    Generally, you design form the basis of viable HTML (or HTML plus
    server-side scripting); creating a system that will get the job done
    (whatever that job happens to be) in the absence of everything on the
    client but the ability to display (in the broadest sense of the word)
    HTML (and submit forms, if server-side scripting is involved, as it must
    be for any commercial application where money changes hands). Starting
    from the basis of a viable HTML (+ server script) design accommodates
    all HTML web browsers that do not provide scripting and provides a
    working fall-back position for all browsers that can be scripted but may
    not provide the facilities/features that any particular script may need.

    From that starting point you add scripting in a progressive, cautious
    and defensive way, so that it enhances the otherwise viable HTML (+
    server-script) system into a system that is in some sense better (or
    even 'good'). You do this enhancement progressively and cautiously
    because at no point should you take any action with your script that
    will render the otherwise viable HTML basis of the design non-viable.

    So you test the environment to verify that it provides _all_ of the
    features your scripted enhancements will need to use prior to taking any
    action that will attempt to employ those features. This as a practice
    refereed to as 'feature detection or, ambiguously 'object detection
    (ambiguously because the term 'object detection' is also used to refer
    to a process that is better labelled 'object inference' where tests
    performed on individual, or small groups of, browser features are used
    to infer the existence of features beyond those directly tested (in
    extremes, entire browser object models are inferred from the existences
    of a single object that is subject to a single test)). Feature detection
    tests are carried out with as near as a one-to-one relationship to the
    features of interest in order that no slightly unexpected browser object
    models fool the script into attempting to do something that is not
    supported (and so may break the viability of the underlying HTML).

    Generally scripted enhancements should be designed to be independent of
    each other, and carry out only the feature detection that each component
    needs for its own operation. There is no reason for the inability of a
    browser environment to support, say, a 'tool tip' script to deny the
    user client-side form validation. Both may be enhancements to the HTML
    but where one is not practical the other may still be.

    The point of this feature detection is to provide the script with the
    ability to make informed decisions about when and how to act, and when
    not to act. And when the results of those tests are an indication that
    the browser environment will not support the script the script will then
    choose not to act, but the system as designed then just falls-back to
    its underlying, and viable, HTML (+server-script) basis. Resulting in a
    system that will get the job done for as close to 100% of possible users
    as is practical.

    Thus true cross-browser scripting is ultimately a design challenge, not
    easy (at least not quick to learn) but also not impossible. Indeed there
    are many effort-saving aspects of rising to the full design challenge,
    for example, it is not actually necessary to worry about scripting
    non-modern, non-dynamic, non-DOM standard browsers, because the feature
    detection will tell your scripts when they encounter these browsers and
    falling-back to the underlying viable HTML (+sever script) basis of the
    design will instantly accommodate all of them.

    Having realised that it is possible to accommodate dam near 100% of
    possible visitors with appropriate design applied to the whole system
    the school of thought that say it is best to solve the problem of
    multiple browsers by only thinking about one or two common browsers in
    their default configurations starts to look like ignorance, idleness, or
    stupidity, especially when you consider that even these one or two
    common browsers may be operated with scripting (or other 'required'
    features) turned off, which would kill those 'idle' designs at a stroke.

    It is not the place of a script author to be arbitrarily limiting the
    viability of a web site that they are working on, out of ignorance,
    stupidity or idleness (unless they own it), and it is particularly
    inappropriate in a commercial context where the turnover, profits and
    long term viability of a paying client may be at stake.

    Richard Cornford, Apr 7, 2006
  6. I would like to see the corresponding list(s). Just curious.

    Thomas 'PointedEars' Lahn, Apr 7, 2006
  7. It is a complete waste of effort to attempt to keep lists of web
    browsers, as a comprehensive list is never going to be a practical
    proposition (and that is assuming that it is easy to agree what
    constitutes a distinct browser: consider Netscapes 4, 6 and 8; three
    very distinct browsers under the same name, and Mac IE in certainly a
    distinct creature form Windows IE).

    My numbers are estimates, however:-

    <URL: >

    - has about 120-odd headings in its browser archive and does not include
    commercial browsers that were never available to be freely downloaded
    (such as IceBrowser) or embedded browsers such as NetFront and AvantGo
    (or whatever it was called), and I don't see browsers for unusual
    hardware/OSs in that list, such as AS400 browsers (and I know that there
    is at least one as I once worked for a company that developed one (not a
    commercial success and probably long dead by now)).

    Richard Cornford, Apr 7, 2006
  8. phal

    Randy Webb Guest

    Thomas 'PointedEars' Lahn said the following on 4/7/2006 2:43 PM:
    <URL: >

    Is but one list/archive of them.
    Randy Webb, Apr 7, 2006
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.