Re: <canvas> and the 2D context API

My thoughts:

1) I believe the technical issues with splitting out  
RenderingContext2D (the Canvas API) can be overcome, given a skilled  
and motivated editor, even though they are nontrivial.

2) Once both HTML5 and the Canvas API are sufficiently advanced, the  
normative cross-references won't be a problem. For future cycles, each  
spec will be able to reference the latest stable version, so each  
would be able to proceed on its own cycle in the long run.

3) The showstopper so far has been, as Anne has pointed out, lack of  
an editor.

I think unless an editor shows up real soon, we'll have to defer  
splitting to the next cycle.

Regards,
Maciej

On Aug 13, 2009, at 10:11 AM, Shelley Powers wrote:

> 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:23:28 UTC