[whatwg] Callback driven initialization of canvas

[Jonas Sicking]

Fabien Meghazi wrote:
> Will it be possible for the browsers to allow an extension such as
> canvas block ?
> 
> My understanding is that it won't be possible (please correct me if
> I'm wrong, I'm not an expert) as the initialization of a canvas
> context is done as follow :
> 
> var canvas = document.getElementById('tutorial');
> if (canvas.getContext){
>   var ctx = canvas.getContext('2d');
>   // drawing code here
> } else {
>   // canvas-unsupported code here
> }
> 
> But if the initialization of the canvas tag was callback driven, then
> I guess it would be possible to do a canvas block.
> 
> var canvas = document.getElementById('tutorial');
> if (canvas.getContext){
>   canvas.getContext('2d', function(ctx) {
>        // drawing code here
>   });
> } else {
>   // canvas-unsupported code here
> }
> 
> With this scheme, I guess it would be possible to hook the getContext
> function and do whathever with the callback function (eg: call it when
> user click the canvas element like flash block)

Callback driven features are definitely important for features where you 
want to engage the user before enabling the feature. For example the 
geolocation specs uses this pattern, as does the FileDialog interface in 
the fileupload draft.

However I'm less convinced that this applies to canvas. You could 
accomplish the same thing by turning off rendering for all canvases for 
a page until the user has opted in. This allows asynchronous opt-in from 
the user, without requiring a callback driven API for the developer.

/ Jonas