- From: Dailey, David P. <david.dailey@sru.edu>
- Date: Sun, 25 Mar 2007 15:13:38 -0400
- 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 UTC