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

> Canvas is therefore best suited for [for what actually? at least one
good example is needed].

Canvas is therefore best suited for situations where all of the
following apply:
- The content in the response requires an image
- The image must be tailored to the current dynamic context
- The response needs to be delivered with maximum efficiency
- The client device does not support multi-part or embedded SVG
- The client device supports Canvas

An example use case: A commuter bus service that sends you a map showing
where you are, where the bus stops are and which stop you should run to
if you want to get to your destination on time.

In this use case, the image is an integral part of the service. The text
(whether as an accompaniment or an alternative) might take you so long
to comprehend that you'll miss the bus. The response is highly
contextual and immediate, and therefore the need for it to be
discoverable is diminished, especially as such content loses its value
rapidly with time. The response needs to be fast, under the
circumstances. Any latency in delivering the image (e.g. because it was
referenced by the main markup and therefore requires another round-trip)
would negatively impact the service. Thus sending the image as (part of)
the response is preferred. If the client supports multi-part then a
raster image could be included with the response (pre-rendered on the
server), or if it supports embedded SVG markup then that could be used
too. The latter is preferred as even a compressed raster could be larger
than an equivalent SVG. However, if neither options are available, but
Canvas is supported, then Canvas is the solution.

Now, what you need to ask yourself is whether or not this sounds like an
"edge case", and whether or not it is worth the effort to support it. Of
course, it could be that you don't have the resources to support
anything other than technologies X, Y and Z, but that's a separate
argument*.

>From my perspective, the statements of best practices regarding visual
resources are doomed because the actual practices will take into
consideration far more issues than the technical matters raised in the
document and this thread. Availability of skills, costs of development,
maintenance costs, current practices of the graphics design shop used by
the customer, and many more factors will determine what is actually used
in practice. While I commend the BPWG for trying to devise some best
practices regarding graphics, I think it would be far more useful if you
merely put together some well-researched pros and cons of all the main
options within your scope (i.e. current open technologies), which we can
then pile into the melting pot along with the claims from vendors of
proprietary alternatives so that we can come up with a reasonable answer
on a *case by case* basis.

You see, the problem is that "best" means different things to different
people. Instead, perhaps the section on graphics should start like this:

"When devising the practices that best suit your particular
circumstances, the following technical features of several popular open
alternatives should be considered:"

Followed by the detailed pros/cons list.

---Rotan


* If you are pressed for resources, you could look into things like
canvas-to-svg and svg-to-canvas solutions, areas that people have
already starting tinkering with.


-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Eduardo Casais
Sent: 04 September 2009 11:04
To: public-bpwg@w3.org
Subject: 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 Monday, 7 September 2009 09:48:15 UTC