phal said:
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.
