The use of client-side scripting (including javascript and DHTML techniques) is acceptable, however please take note of the following points:
1) The site must still be accessible to browsers which are not scriptable. Use <noscript>< tags and "sniffer" routines to determine the client capabilities and provide content-equivalent pages to non-scriptable browsers.
2) Thoroughly test your pages for functionality under a wide range of browser / platform configurations.
A few general comments on client-side scripting:
There Is More Than One Javascript...
Javascript is supported in various flavours on browsers according
to version and manufacturer. "Javascript" is the name given to
the scripting language developed by Netscape and has also come to
mean the generic client-side scripting language. JScript is the
Microsoft equivalent. ECMAscript is the published open standard,
to which proprietary flavours of the language _should_ adhere.
Note however that ECMAscript defines the underlying structure of
the language, but not specific issues, which are addressed by the
Domain Object Model. The DOM too has a standardised structure,
defined by the W3C group.
Internet Explorer also supports VBscript, based on Visual Basic. This will not work in other browser versions.
( ECMA = European Computer Manufacturing Association )
USE "language" Attributes in <script>
Tags:
The version of javascript can be specified in the SCRIPT tag.
This can be useful for branching code, particularly when used in
conjunction with the "src" attribute'.
DHTML: What Is It?:
The term DHTML (Dynamic HTML) is a marketing term which denotes
the use of a client-side scripting language (normally
JavaScript/ECMAScript) to manipulate HTML and CSS properties.
Use of DHTML is compatible with the open standards developed by W3C, and so its use is OK from a standards point of view.
<noscript> Tags:
Use <noscript> tags where appropriate to deliver equivalent
content to browsers which do not support javascript or where
script processing has been disabled.
Accessibility:
Regardless of how javascript is used on the page, the overriding
principle for NOF projects is that the page must still be
accessible to non-javascript enabled browsers.
Future Proofing:
As new versions of browsers are released and new ways of
accessing web resources come into existence there is a need for
projects to test their content against these new interfaces. This
is true for all web content, but the situation is more acute when
pages include script. Projects should build into their plans a
provision for undertaking these checks and for making corrections
to HTML and script as necessary.
Script Block Content Shielding:
Commenting within <script>tags to prevent inclusion of the
script by browsers that do not understand the <script> tag.
Wrapping the text in HTML comment tags prevents these browsers
from displaying raw javascript on the page. Admittedly this is
highly unlikely now, however it is good defensive programming
practice.
<script> <!-- ...javascript goes here // --> </script>
Browser Detection Aka Sniffing:
It is superior to test for the component of the DOM that you
which to use rather than parsing the navigator.userAgent
property. For example, to create a rollover script for images,
you would code:
if (document.images){
file://image loading / swapping routine
}
Proportion Of Javascript-Enabled
Browsers:
Figures for the numbers of javascript enabled browsers are
difficult to interpret. These figures can be derived in two ways:
by making assumptions based on the userAgent or by placing a
testing script on a web page and recording results. Measuring
from the userAgent value can be done from the server access log
but it takes no account of the setting of the browser, so the
assumption that, say IE5.5 is javascript enabled is not always
true. The nimda virus outbreak last year highlights this. Many
people were advised to turn off scripting in their internet
settings to protect themselves from nimda.