Re: <canvas> and the 2D context API

On Thu, 13 Aug 2009 18:49:33 +0200, Shelley Powers <shelleyp@burningbird.net> wrote:
> Is that the only instance where the HTML 5 specification drills down  
> into the Canvas element's 2D API directly?
>
> Again, this is a handshake issue, whereby one requirement the HTML 5  
> specification would have is the ability to obtain a serialization of the  
> Canvas object. This is an unfortunate consequence of merging and  
> breaking down borders between API and declarative syntax, but I don't  
> see it as a showstopper.
>
> There's nothing in this _requirement_ that would overly inhibit  
> innovation on the Canvas object. Nor is there anything likely to happen  
> with the Canvas object, the 2D immediate mode API, that would impact on  
> this handshake between specifications.
>
> But you are right, in this would be normative, not informative. I don't  
> see this as a showstopper though, unless we're constrained by HTML 5 not  
> being able to specify a normative reference to the new 2D API, because  
> the 2D API doesn't have a published specification yet.
>
> In which case, I would think it better to remove the reference to  
> ImageData from PostMessage. It could be taken up again in a later HTML  
> specification, as folks are fond of saying. I've looked at the existing  
> implementations of PostMessage for the various browsers. None have  
> implemened ImageData yet. Even if they had, this is the risk they take  
> for implementing what's current in a working draft.
>
> As Philipe stated in the HTML-WG IRC, implementations may not support  
> passing ImageData objects directly[1], at least with Worker Threads.
>
> This is not a showstopper.

No, the showstopper has always been lack of an editor. However, I thought part of your argument was the need to innovate quicker than we currently do. If we consider ImageData processing in separate processes to be important having to take it out because of the way we edit our specifications seems like it would hinder this particular innovation and be a potential disadvantage of this approach, rather than an advantage.


> [1] http://krijnhoetmer.nl/irc-logs/html-wg/20090802#l-61


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 13 August 2009 16:56:45 UTC