By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,474 Members | 966 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,474 IT Pros & Developers. It's quick & easy.

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

P: n/a
Hi

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

Apr 6 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
phal wrote:
I think there are many different browsers to browse to the Internet,
Vast numbers.
how can I write the javascript to identify different browser and
display according to the users.
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?
Some browser disable the javascript by default or by the user, how can i
solve this problem if the javascript is disable.


What is the actual problem? Why do you want to know what browser is being
used?

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Apr 6 '06 #2

P: n/a
If you adopt X library ( http://cross-browser.com)
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

Apr 7 '06 #3

P: n/a
zh******@gmail.com wrote:
If you adopt X library ( http://cross-browser.com)
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.
<URL:http://pointedears.de/scripts/test/whatami#inference>
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


That is utter nonsense, and I do not have to read the source code to come
to that conclusion.
PointedEars
Apr 7 '06 #4

P: n/a
phal wrote:
I think there are many different browsers to browse to the
Internet,
At least 150, 40+ of which can be scripted.
how can I write the javascript to identify different browser
You cannot, but you don't need to so not being able to do so is not a
problem.
and display according to the users.
You want to tell the user which browser they are using? Why, if they
don't already know they probably couldn't care less.
Some browser disable the javascript by
default or by the user,
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.
how can i solve this problem if the javascript
is disable.


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.
Apr 7 '06 #5

P: n/a
Richard Cornford wrote:
phal wrote:
I think there are many different browsers to browse to the
Internet,


At least 150, 40+ of which can be scripted.


I would like to see the corresponding list(s). Just curious.
Regards,
PointedEars
Apr 7 '06 #6

P: n/a
Thomas 'PointedEars' Lahn said the following on 4/7/2006 2:43 PM:
Richard Cornford wrote:
phal wrote:
I think there are many different browsers to browse to the
Internet,

At least 150, 40+ of which can be scripted.


I would like to see the corresponding list(s). Just curious.


<URL: http://browsers.evolt.org/ >

Is but one list/archive of them.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Apr 7 '06 #7

P: n/a
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
phal wrote:
I think there are many different browsers to browse
to the Internet,


At least 150, 40+ of which can be scripted.


I would like to see the corresponding list(s). Just curious.


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: http://browsers.evolt.org/ >

- 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.
Apr 7 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.