Preliminary review of the svg parts of the MWABP spec

On Thu, 08 Oct 2009 16:26:09 +0200, Erik Dahlstrom <ed@opera.com> wrote:

...
> This is a transition announcement for the Last Call Working Draft of the
> Mobile Web Application Best Practices, published today at:
> http://www.w3.org/TR/2009/WD-mwabp-20091006/
...
> The Last Call review period extends until 6 November 2009, and we would
> be grateful if your group could review the document once more, in
> particular:
...
>     * for the SVG WG, for the specific best practices on Canvas and SVG.

Comments on the section about SVG and Canvas.

== http://www.w3.org/TR/2009/WD-mwabp-20091006/#bp-canvas

- typo: primatives

[[
   In contrast, SVG is an XML language for defining vector graphics -- the  
nodes and elements are added to a DOM and can be modified later using  
JavaScript.
]]

The XML-only-part is likely going to change since SVG is part of HTML5.

I'd maybe phrase it a bit differently:
"In constrast, SVG is a retained-mode vector graphics format -- this means  
that most of the state and drawing commands are available in the DOM for  
later modifications, image scaling operations or for inspection (e.g by  
accessibility tools), through ECMAScript or by use of SVG's set of  
declarative animation elements."

[[
   SVG is well-suited for graphics that must be scalable and whose  
components need to be modified (e.g. panning and zooming a map) whereas  
Canvas is best suited for cases where a static bitmap is sufficient (e.g.  
drawing a scatter-chart, visual effects, reflections etc).
]]

Suggest replacing "that must be scalable and whose components" with "that  
must be scalable and/or whose components".

Also I see no particular reason why scatter-charts, visual effects and  
reflections shouldn't be done in SVG. In the scatter plot case it might be  
advisable to go with canvas if you are not interested in providing more  
accessible/indexable information about the scatter points at all.

Canvas is good for games, or other cases where the underlying DOM is not  
very important to the presentation. It's also well suited for porting  
applications from native code, since the Canvas API maps well to existing  
drawing APIs on desktop operating systems. For the cases where the SVG DOM  
is too large for a particular device canvas can be a better choice,  
however it can also be used in combination with SVG to get the benefits of  
both technologies.

[[
In most cases Canvas is faster and should be preferred if it meets  
requirements. However, since Canvas generates a flat bitmap it is not  
inherently accessible and so should not be used as the sole means of  
conveying information.
]]

Since canvas is a lowlevel API compared to SVG it has the potential of  
being faster.

For scalable images and/or for images that are reused many times in  
various sizes SVG is probably a better fit.
For the cases where having a DOM helps accessibility SVG should also be  
preferred.

Further recommended reading:
http://svgopen.org/2009/papers/54-SVG_vs_Canvas_on_Trivial_Drawing_Application/
http://ajaxian.com/archives/todataurl-canvas-and-svg

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 13 October 2009 19:58:42 UTC