Re: Canvas 2D API specification update - defining the element or not

Martin Kliehm wrote:
> My first reaction to separating Canvas from the HTML5 spec was positive 
> since I believe there's no way to address accessibility sufficiently in 
> time for a Last Call, and because other parts like Geolocation have been 
> successfully separated before.

Geolocation has not been separated, since it was never part of the HTML5 
spec and was not worked on by the HTML WG or WHATWG.

> Also we are now speaking of the 2D 
> context, soon there needs to be an extension (I admit I still love the X 
> of XHTML) for 3D anyway.

It already exists and is being implemented (though I don't think any 
specification has been published yet); see e.g. 
<http://www.khronos.org/news/press/releases/khronos-webgl-initiative-hardware-accelerated-3d-graphics-internet>. 
As far as I'm aware, the location of the canvas definition and 2D 
context definition has no significant impact on the ability for other 
groups to define additional contexts.

> I'm 
> afraid that taking it out of the general spec won't prevent browser 
> vendors from implementation, sans accessibility, which is inacceptable.

It's already been implemented natively in at least four desktop browser 
engines, years ago, so it's far too late to prevent implementation.

> But I'd like to question if this is the right path to get to our goal: a 
> timely implementation of accessible solutions in browsers supporting 
> HTML5.  Do we really gain time by separation?  Is it possible to even 
> gain speed with a highly motivated expert team focusing on this single 
> issue?  Can we ensure that implementors of HTML5 regard the Canvas spec, 
> or is keeping it together a better strategy?
> 
> What's your opinion?

 From what I've seen, progress on improved canvas accessibility 
solutions seems to be limited primarily by nobody having proposed 
solutions that are better than what's already supported.

The only way to achieve useful progress would be to propose and develop 
solutions. Separating the canvas spec would take up time that could be 
spent making progress on solutions.

The argument here seems to be that progress will be made eventually, but 
will take long enough that HTML5 will be in LC and won't be able to make 
significant changes, and so separating the canvas spec will avoid a 
situation where solutions have been developed but can't be adopted into 
HTML5. I don't find that argument very convincing, for a few reasons:

* It seems very likely that HTML5 will go to LC then back to WD then 
back to LC again (perhaps multiple times), since the first Last Call 
will raise a lot of substantial comments. So there will be plenty of 
opportunity within the W3C Process to make substantial changes to HTML5 
(such as adding new canvas accessibility solutions).

* If the canvas spec is split in order to facilitate accessibility 
solutions, before we have any idea what those solutions will look like, 
the split might be incompatible with the best solution. E.g. we might 
split out the 2D context and keep the <canvas> element in HTML5, but 
then discover the best accessibility solution involves modifying the 
<canvas> definition. It seems premature to split it now for that 
purpose, before having decided even roughly on any new accessibility 
solution.

* Even if the LC->WD->LC thing didn't happen, the W3C Process seems to 
allow for the first HTML5 LC to say the canvas feature is "at risk" and 
then it could be removed (and added to a separate spec) before moving to 
PR. That would give time to develop accessibility solutions, before 
deciding if/how to best split canvas out of the HTML5 spec.

* Every other feature in HTML5 will need to continually evolve - the 
interoperable implemented web platform won't be frozen just because the 
spec was assigned a certain level by the W3C. So there will need to be a 
general solution for updating HTML in the future, and the general 
solution would apply equally well to canvas.

So I don't think the timeline issue is a good reason to split the canvas 
spec: it would be fine to work on canvas accessibility designs now 
(perhaps in the public-canvas-api list), and it will be easy enough to 
adopt the designs into HTML when they're ready, and they won't get 
dropped and forgotten just because of Process issues.

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Friday, 23 October 2009 12:55:56 UTC