ACTION-924: canvas and SVG draft text / comments

I have a few remarks to the draft section on SVG/Canvas 
posted by Jeff Sonstein.

1.	SCOPE

The text entirely omits discussing Flash (lite), although
this technology is squarely in the scope of SVG and canvas,
has been available on mobile devices for far longer than 
canvas, and its availability is very much comparable to
SVG. Flash lite is much more utilized in many markets than
SVG -- I believe it is the situation in the Far East; the 
W3C Korean colleagues could confirm or deny this.

Ignoring this important technology is not exactly a good 
service to the developers' community. I surmise there is 
a reluctance to deal with proprietary approaches, but then 
the text should make a honest stand and clearly justify 
why Flash lite is not being considered in best practices.


2.	TECHNOLOGY APPLICABILITY

It seems to me that the differences between both technologies
are presented in a somewhat misleading form. As a matter of 
fact:

a) "Both SVG and the Canvas tag [...] are useful for their 
generalized drawing capabilities": SVG does not just supports
drawing; it also features animation capabilities, management 
of user-related events, linking, and, in the case of the 
latest SVG tiny 1.2, even multimedia (synchronized audio, 
video, graphics).

b) "Use Canvas where drawn contents (blocks) are to be 
under the control of JavaScript": with SVG tiny 1.2, one
can manipulate the graphical elements with Javascript as
well.

c) "Use Canvas Tag For Dynamic Graphics": from its
capabilities, SVG appears to be as well-suited as Canvas 
for dynamic graphics. In fact, the proposed text mentions
"Use SVG where drawn elements (children) must be available 
as data and may be manipulated dynamically" -- clearly
implying that canvas is not appropriate for dynamically
handling graphical objects.

SVG is more richer and more powerful than Canvas -- and
as a consequence, substantially more complex. There are
also important differences between the main versions of 
SVG actually implemented on mobiles (tiny 1.1, 1.1+ and 
1.2; basic is exceptionally, if at all, supported). These 
characteristics should be made explicit in the document.

Another fundamental issue is why an application would
require its graphical content "being visible [probably
meaning 'manipulatable'] as data" or not. A couple of 
short examples would be in order (from simply panning 
and zooming graphs as in maps, to more complex 
manipulations such as the edition of technical diagrams, 
vs. drawing pure fixed user interface elements such as 
buttons).


3.	DETAILED COMMENTS

"Given the extremely wide variety in performance due to 
the large number of combinations and permutations of 
handset hardware and operating system, it made sense 
to me to remove all references to speed": it may still
make sense to mention performance if one can make a
substantiated, reasonable consideration about the 
spread of performance in both technologies. As a 
developer, knowing that performance with technology
A varies a lot more across various target devices and
OS than with technology B is useful information.


"Due to the user-interface requirements of mobile devices,
[...etc...]": This is actually a very relevant 
discussion, but I wonder whether it should not be
placed on its own section elsewhere, as it is a general
issue for scripting and markup in mobile devices.


"For example:" This should be completed with the skeleton
of the drawButton script function. 

<script type="application/ecmascript">
function drawButton(canvasId) { ... } </script>


That would be it. I hope I am not making myself unpopular
with the MWABP editors.


E.Casais

Received on Tuesday, 1 September 2009 15:43:53 UTC