Draft Content for W3C BPWG Action 910

Comments and feedback on this item very welcome.

-----  snip  -----
3.5.12 Use Canvas Tag For Dynamic Graphics

Both SVG and the Canvas tag are becoming available in an increasing range of
mobile browsers and applications, and are useful for their generalized drawing capabilities.
Developers should differentiate between circumstances where simple HTML UI elements 
are appropriate for semantic clarity, where the node structure of an SVG sub-tree of 
more graphically-complex elements should be be present to allow DOM-based access to 
the rendered image(s), and circumstances where the "blank slate" dynamic content-drawing 
capabilities of a Canvas element are more useful.

3.5.12.1 What it means

A rich variety of user interface controls (buttons, labels, etc) are made available to the 
developer by HTML/XHTML. For the sake of semantic clarity, developers should use these 
elements where simplicity, text-based controls, and semantic clarity in the source code are 
desireable and appropriate. SVG is an XML markup language, and graphically-rich SVG elements 
and attributes become a part of the DOM and are rendered by the application context browser. 
Canvas is a "blank-slate" and singular drawing element, the drawn contents of a Canvas 
element do not become a part of the DOM, and drawing into a Canvas element is performed 
by JavaScript acting on the rendered display.

Use SVG where drawn *elements* more complex than the normal compliment of the 
HTML/XHTML UI palette must be available as DOM-level data for examination and 
manipulation. Use Canvas elements where drawn *contents* are to be under the dynamic 
control of JavaScript and do not require being visible as DOM-level data.

3.5.12.2 How to do it

Canvas elements are typically drawn into at load time, using an "onload" event-handler. This will
require assigning a unique id to any given Canvas element, and passing that id or set of ids to the
JavaScript "onload" drawing function or functions.

Canvas element width and height must be specified within the HTML, to provide the browser
with sufficient layout information to properly receive the drawn contents.

Events generated by user actions/gestures on a Canvas element may be captured and
handled. Due to the user-interface requirements of mobile devices, "onclick"
events are probably the only appropriate events to handle. Events such as "onmousedown",
"onmouseup", "onmouseover", "onmouseout", and so on are unreliable for cross-platform coding
in an environment where user-gestures are generally confined to simple finger- and stylus-taps.

For example:

[...]
<body onload="drawPathBasedDisplayElement( 'myCoolPathBasedDisplayElement' );">
 <canvas id="myCoolPathBasedDisplayElement" width="150" height="150" 
             onclick="morphPathBasedDisplayElement( 'someMessage' );"></canvas>
[...]

-----  snip  -----
    

Content on this site is provided by Prof. Jeffrey Sonstein under a Creative Commons License. Please contact me, if you wish more information about my work.