W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

RE: brainstorming -- SVG

From: Dailey, David P. <david.dailey@sru.edu>
Date: Sun, 25 Mar 2007 15:13:38 -0400
Message-ID: <1835D662B263BC4E864A7CFAB2FEEB3D258B93@msfexch01.srunet.sruad.edu>
To: "Henri Sivonen" <hsivonen@iki.fi>
Cc: <public-html@w3.org>


Fri 3/23/2007 2:24 PM
Henri Sivonen [mailto:hsivonen@iki.fi] wrote:

> 6. Much of the specification of WHATWG's <canvas> is redundant with 
> and syntactically inconsistent with SVG.

<canvas> provides a drawing API that is backed by running code in 
shipping products. SVG is for serializing vector graphics.
There is http://fuchsia-design.com/CanvaSVG/
What I have in mind is something like this: if there are to be two different W3C graphics standards for client side drawing (see also http://srufaculty.sru.edu/david.dailey/svg/Draw018.html as an example of "drawing" using SVG) then why can they not at least share as much grammar as possible? 
For example, is it feasible for <canvas> and <svg:path> to share the same path descriptor strings?
By that I mean something of the following sort
SVG -- <path d="M 0 0 C 100 100 200 0 300 100 L 200 400 z" [...]>
and Canvas (proposed)-- CurrentPath.makePath("M 0 0 C 100 100 200 0 300 100 L 200 400 z" )
where the makePath method of the CurrentPath would be a short-hand alternative to the current methods that I think would require using the beginPath(), bezierCurveTo(), lineTo(), and closePath() methods. It's possible that I've overlooked something in <canvas>.  At least then one could directly apply the output of something that draws SVG into <canvas> should HTML support of SVG remain forever elusive.
David Dailey
Received on Sunday, 25 March 2007 19:13:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 25 March 2007 19:13:27 GMT