Some comments on The Canvas 2D API 1.0 Specification

Hello public-canvas-api,

here are a few comments on the Canvas 2D API 1.0 spec,

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,

> 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  

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.


Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog:

Received on Monday, 7 September 2009 12:58:52 UTC