- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 07 Sep 2009 14:54:29 +0200
- To: public-canvas-api@w3.org
Hello public-canvas-api, here are a few comments on the Canvas 2D API 1.0 spec, http://dev.w3.org/html5/canvas-api/canvas-2d-api.html. 2.1. The canvas interface element === > interface CanvasElement : Element Why does the interface need to inherit from Element? Isn't it more straightforward that the element that wants to use the canvas functionality inherits the CanvasElement interface instead? I'd prefer it if the CanvasElement interface was completely standalone. 3.3 Compositing === > lighter A plus B. Display the sum of the source image and destination > image, with color values approaching 1 as a limit. Why isn't this named 'plus' or 'add' instead? 'plus' would be consistent with PorterDuff, 'add' might be better if there's an intention to add a 'subtract' mode in the future. Note that it's possible to confuse this with the 'lighten' blendmode, http://www.w3.org/TR/SVG11/filters.html#feBlend. > vendorName-operationName Vendor-specific extensions to the list of > composition operators should use this syntax. Why is this needed? Isn't the getContext() method enough to deal with vendor-extensions? 3.10 Images === > Each of those three can take either an HTMLImageElement, an > HTMLCanvasElement, or an HTMLVideoElement for the image argument. It would be good to allow this set to be extended, e.g with SVGImageElement. The same also applies to the createPattern method. It wouldn't be natural to use HTMLImageElements in an all-svg document. 6. Security with Canvas Interface Elements === Should probably be extended to deal with other inputs, e.g SVGImageElement. 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 Monday, 7 September 2009 12:58:52 UTC