ACTION-719 [5.9.4 Javascript/ECMAScript]

5.9.4 Provide Alternatives to Advanced Javascript/ECMAScript What it means

Scripted applications, e.g. using asynchronous I/O methods or  
in general, may not be supported by some browsers. Pages designed to  
use scripting will
require alternate approaches in browsers that do not support  
scripting, so you should
be prepared for that and provide similar functionality in case  
scripting is not available. How to do it

Detect browser capabilities or user preferences, and react accordingly  
with graceful
degradation or progressive enhancement of Javascript/ECMAScript.

  Design targeting purely desktop/laptop audiences (where  
media="screen") tends to be
  structured to degrade gracefully if ECMAScript/Javascript is not  
present or if advanced
  capabilities like asynchronous I/O (and other "AJAX" techniques) are  
not supported.
  Design targeting a mixed audience of mobile (where media="handheld")  
  desktop/laptop users should be structured to both degrade gracefully  
  ECMAScript/Javascript is not present) and likewise to progressively  
enhance page- and
  user-behavior capabilities (if ECMAScript/Javascript does turn out  
to be present).

Separate behavior from content and presentation, for graceful  
degradation and
progressive enhancement.

  Good logical design separates XHTML content (the "data model"), CSS  
  (the "view"), and ECMAScript/Javascript behavior (the "controller").  
  targeting purely desktop/laptop audiences (where media="screen")  
tend to duplicate this
  in the physical site structure, placing each in its own file and  
having pages issue an HTTP
  request for each separately through use of the <link/> or <script/>  
tags. Designers targeting
  purely mobile (where media="handheld") audiences tend to interleave  
the three concerns
  into one physical payload/file delivered to the client in order to  
reduce per-request charges.

  Designers targeting a mixed audience of mobile and desktop/laptop  
users can build
  Web pages which load sufficient ECMAScript/Javascript (in the <head/ 
 > element) to
  determine device display and interaction capabilities when first  
loaded. This allows
  for progressive enhancement, just as good structural design of XHTML  
allows for
  graceful degradation.

  Techniques similar to progressive enhancement of CSS (see 5.x.y) may  
also be used
  to inject event-handling Javascript/ECMAScript code into files at  
request-time and
  to attach Javascript/ECMAScript behaviors at run-time for  
progressive enhancement.
  In the example below, page-scope variables and functions are  
declared in
  a <script/> element in the <head/> while run-time test code for
  progressive enhancement is declared in a <script/> element in the  
  element (to allow the DOM to be loaded before the code runs):

[NOTE to WG:
  for complete code as running example]

<?xml version="1.0" encoding="utf-8"?>
<html xmlns="" xml:lang="en">
  <meta http-equiv="content-type" content="application/vnd.wap.xhtml 
+xml; charset=utf-8" />
  <meta http-equiv="cache-control" content="no-cache" />
	<title>Javascript Insertion Test</title>
	<style type="text/css" media="all">
/* <![CDATA[ */
#testMe {
  border: thin solid red;
/* ]]> */
  <script type="text/javascript" charset="utf-8">
// <![CDATA[
var someVariable;
var triggerTest = 480;
function actualValue() {
  return someRuntimeValue;
function setSomeVariable( newValue ) {
// ]]>
  <p id="testMe">
    Please click on this area to test this scripting example.
  <script type="text/javascript" charset="utf-8">
// <![CDATA[
function thisFunction() {
  [do something, possibly using someVariable]
if( actualValue() >= triggerTest ) {
  setSomeVariable( 'some new value' );
  document.getElementById( targetID ).onclick = thisFunction;
// ]]>

Received on Thursday, 27 March 2008 13:14:30 UTC