- From: Dailey, David P. <david.dailey@sru.edu>
- Date: Sat, 7 Apr 2007 21:45:45 -0400
- To: "Doug Schepers" <doug.schepers@vectoreal.com>, <public-html@w3.org>
On Thu 4/5/2007 6:40 PM Doug Schepers wrote (concerning the WHATWG <canvas> proposal >There are some good opportunities for synergy with SVG as regards >raster- and pixel-based interfaces. +1 Whether this is considered here or somewhere else, it ought to be considered. The two each have things the other could benefit from. If our objective is to extend HTML into the web applications arena while not breaking the web, it would almost seem to mandate that consideration. Among the areas of synergy I can see are a) sharing of path syntax (Maciej has hinted as some receptiveness to that, I think) b) being able to read and write pixel values generated by SVG (SVG could use that -- canvas offers it) c) applying SVG filter and filter primitives to <canvas> drawings (bitmaps plus filters are pretty cool, one could argue) d) exporting <canvas> path arguments via script as objects to DOM in the manner of SVG e) sharing top billing within the DOM: if SVG vectors and external JPG's could both be pixel-analyzed as per <canvas> then lots of fun can begin. f) sharing a common top level definition of gradient objects -- that seems like it might end up being valuable in such areas as CSS and forms. I don't know how bloated HTML has to become before it becomes too bloated, but it seems like a good deal of the bloat is caused by quirks, and since several browsers now seem to have SVG and a nontrivial subset of those (Safari, Opera, Firefox) already have Canvas, I don't see a whole lot of extra code or spec being required to make the two things work together. David Dailey
Received on Sunday, 8 April 2007 01:45:37 UTC