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

> 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.
>

But splitting off specifically because of accessibility issues has
never been the primary reason. Working towards accessibility with
Canvas would be aided by splitting off Canvas, but that wasn't the
primary reason.

> 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).
>

I don't think it's a good idea to depend on failures happening in the
rollout process for HTML5, as a way of incorporating improvements into
Canvas.


> * 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.
>

Again, accessibility was one reason given, but not the only reason given.

> * 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.
>

Again, waiting for a perceived failure to happen with HTML5 to improve
Canvas seems self-defeating.

> * 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.

Again, though, there's no reason for Canvas and HTML5 to be tied at
the hip, forever having to go hand in hand into future web.

One is an improvement on previous versions of HTML (including XHTML
serialization and DOM). The other is a 2D Graphics API. From my
understanding the only reason Canvas is in HTML5 is some patent issue,
and the fact that a few years back, no one was willing to do the work
to split Canvas off, or form a team to improve and maintain Canvas.
What's changed is there is a group willing to split the spec, and
maintain a separate Canvas. The additional work to ensure the split
happens cleanly probably won't take more (as has been estimated) 8-10
hours.

Considering all of the amount of time necessary to improve Canvas, and
incorporate accessibility, I would think the already overworked, and
over emailed HTML WG would welcome the simplification.

But I digress. Your email was about the reason for Canvas splitting
off, and I wanted to assure that, though accessibility is one reason,
it's not the only reason. I'd also like to hear back from you the
reverse: why do you think it's better to keep Canvas in HTML5?


>
> 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.
>

Again, I would like to hear from folks why they think Canvas, a 2D API
specification that has managed to do OK without being in an HTML spec,
absolutely requires being in HTML5?

> --
> Philip Taylor
> pjt47@cam.ac.uk
>
>

Shelley

Received on Friday, 23 October 2009 15:16:01 UTC