Re: <canvas> and the 2D context API

Anne van Kesteren wrote:
> 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
>>     
>
>
>   
And perhaps the way its coded in the HTML 5 specification is not the 
best approach.

However, I'm not adverse to it being a normative reference in the HTML 5 
specification, but I am concerned about the procedures in place at the 
W3C about this normative reference.

Or perhaps the real issue since the W3C saw fit to disregard its typical 
procedures when it comes to HTML 5, it can also disregard its procedures 
when it comes to spinning of sections of the HTML 5 document, because 
it's better to do so .

In other words, we can spin the 2D API into a separate specification, 
with the understanding that there is a normative reference between it 
and the HTML 5 specification, and even if the 2D API speeds ahead, or 
doesn't while it establishes its footing, the real key is that as long 
as the handshake is honored, maturity level may, or may not, be within 
one level of each other at any exact moment.

Now, if at a later point, the 2D API group were to define a better 
approach, whatever version of the HTML specification could then discuss 
whether to incorporate the new version, with the understanding that the 
older version is only deprecated, not obsolete.

For this particular case, though, I doubt there would be a "better" 
approach, because all this is, is a snapshot of a square of canvas, and 
pixel states (color) at the time, with appropriate getters/setters to 
get and set the pixel data. Unless I'm missing something mystically more 
complicated.

Shelley

Received on Thursday, 13 August 2009 17:13:03 UTC