Re: ACTION-924: canvas and SVG draft text / comments

Let me attempt to improve the text directly. Feel free to tear this contribution 
apart and condense it.
 

3.5.12 [the real message we want to convey]

Graphics can be incorporated in a mobile application in several ways. The canvas tag 
is a recent markup addition, to be standardized in HTML 5, which provides a "blank 
slate" 2D content-drawing capability to be filled in via Javascript code. SVG and
Flash lite have been available for several years in a range of terminals, and provide
extended functions for animation, multimedia, and dynamic manipulation of objects,
besides the definition of structured, scalable graphics.

These various technologies vary in their binding to Web applications, with
consequences on the kind of graphics manipulations they allow.


3.5.12.1 What it means

Canvas is a singular, flat drawing element. Drawing onto a Canvas element is performed
by JavaScript acting on the rendered display. Since graphics defined with Canvas 
actually consist of Javascript code, the optimizations described in section 3.4,
notably 3.4.5 "Minimize External Resources", can be applied. Because the graphics
object is procedurally defined, it is not discoverable as such (for instance by search
engines), and entails additional processing overhead on the end device compared to a
pre-defined static graphical file. Canvas is therefore best suited for [for what
actually? at least one good example is needed].

SVG is an XML language; graphical objects are defined declaratively and rendered by 
the application context browser. In contrast to Canvas, SVG elements and attributes
become part of a DOM, and can therefore be manipulated explicitly with Javascript. Not
all browsers support inline SVG directly within the main page markup, and those that
do may restrict inline SVG to XHTML pages. This has subtle consequences: the DOM tree
of an inline SVG object is integrated in the main document DOM tree, whereas external
SVG object may have a separate DOM tree. When relying upon AJAX to build SVG objects 
dynamically, this is only possible if the browser supports inline SVG [AJAX 
specialists, please confirm, but from what I know this is the case]. Of course, 
optimizations for SVG as an external resource are more limited than for inline SVG. 
SVG is well-suited for graphics that must be inherently scalable and whose components
have to be manipulated directly through DOM. Examples are panning and zooming 
geographical maps, or editing structured diagrams interactively.

A proprietary technology such as Flash lite provides rich functionality, but, as it is
meant to be a complete run-time environment, its functionality is closed (it does not
integrate with the enclosing page), and raises additional security issues because of 
accesses to device capabilities and such mechanisms as non-standard cookies.

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 should be specified within the HTML, to provide the 
browser with sufficient layout information to properly receive the drawn contents,
as well as a fallback in form of a static graphics file, in the case Javascript is
disabled or Canvas insufficiently supported.

For example: 

<body onload="drawButton( 'myButton' );">
[...]
	<canvas id="myButton" width="150" height="150"
		onclick="alert( 'clicked' );">
		<img src="thefallback.png" alt="a nice image" />
	</canvas> 
[...]
	<script type="application/ecmascript">
		function drawButton(canvasId) { [...script code...] }
	</script>
[...]
</body> 

While SVG tiny 1.2 is being implemented in an increasing number of terminals, the
safest default with mobile devices is to assume SVG tiny 1.1. SVG can be included 
inline directly within markup supporting XML name spaces as follows:

<html xmlns="http://www.w3.org/1999/xhtml" 	
	xmlns:svg="http://www.w3.org/2000/svg" 
	xmlns:xlink="http://www.w3.org/1999/xlink">
<body>
[...]
	<svg:svg>
		[...SVG declarations...]
	</svg:svg>
</body>

All browsers supporting SVG allow it to be included as an external resource via the
<object> tag; a fallback should be provided. Support for SVG via <iframe> or <img> is
inconsistent and not recommended. Example:

<object type="image/svg+xml" data="thesvgfile.svg" width="..." height="...">
	<img src="thefallback.png" alt="a nice image" />
</object>

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


E.Casais

Received on Friday, 4 September 2009 10:04:13 UTC