Re: Some comments on The Canvas 2D API 1.0 Specification

On Thu, 01 Oct 2009 20:55:44 +0200, Frank Olivier <franko@microsoft.com>  
wrote:

> Re Erik Dahlstrom's mail on Mon, 07 Sep 2009 14:54:29 +0200
>
>> 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.
>
> Inheriting from Element seems natural...Could you elaborate on 'more  
> straightforward'?

I meant from a spec reusability standpoint, the HTML5 'canvas' element[1]  
already implements the HTMLElement interface, which in turn implements the  
Element interface.

In a similar way the SVG 'image' element (which has been discusssed in the  
SVG WG as a possible element from which a canvas context could be  
accessed) already implements the SVGImageElement interface, which in turn  
implements the SVGElement interface, which in turn implements the Element  
interface.

If the CanvasElement interface[3] really needs to implement Element then  
I'd prefer making that a requirement on the spec that wants to use the  
CanvasElement functionality, not through the IDL definition since it looks  
to me like that implies a multiple-inheritance conflict. I'd prefer it if  
the CanvasElement interface was defined as a 'pure' interface (read:  
without inheriting any other interfaces).

>> 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.
>
> Safari 4 supports 'lighter' and 'darker' today.
> Is your proposal to change 'lighten' to 'add'? I don't think this change  
> is worth the compat impact, but I'd love to hear more opinions.

Well, if there really is that much content relying on that particular  
functionality (from a draft spec no less) then an option would be to keep  
the old keyword and add an alias that does the same thing. For consistency  
I'd prefer it if the keywords matched what's in the SVG Compositing  
spec[4] and SVG 1.1 [5][6], noting that HTML5 has expanded out src to  
source and dst to destination. As an author I do prefer the abbreviated  
style, i.e src and dst.

>>> 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?
>
> IMHO using a vendor-specific tag to an existing method using this  
> mechanism is fine.
> To check if a particular vendor-specific tag is supported, the following  
> could be used:
>
> previous = context.globalCompositeOperation;
> context.globalCompositeOperation = vendor-specific;
> if (previous != context.globalCompositeOperation) do the vendor-specific  
> drawing
> (This relies on the "Unknown values are ignored" part of the spec)
>
> IMHO getContent(vendor-extension) should be used when the vendor wants  
> to add new *methods*.

Sounds like good examples/notes to put in the spec.

My concern is that authors will fail to do that check, or ignore to do so  
if there's a de-facto standard, and also that a vendor may chose to not  
let a particular mode be standardized by the W3C so that it's covered  
under the W3C patent policy.

Cheers
/Erik

[1] http://dev.w3.org/html5/spec/Overview.html#the-canvas-element
[2] http://dev.w3.org/html5/spec/Overview.html#htmlelement
[3]  
http://dev.w3.org/html5/canvas-api/canvas-2d-api.html#the-canvas-interface-element
[4] http://www.w3.org/TR/2009/WD-SVGCompositing-20090430/
[5] http://www.w3.org/TR/SVG11/filters.html#feComposite
[6] http://www.w3.org/TR/SVG11/filters.html#feBlend

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 8 October 2009 12:08:59 UTC