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

Shelley Powers wrote:
>> 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.

I wasn't commenting on any other reasons - I was only saying that I 
don't think splitting the spec would be helpful for the accessibility 
issues that have been brought up in this discussion, and so I don't 
think it is an argument in favour of splitting the spec.

There are other possible reasons (e.g. wanting to reuse the API in other 
technologies with similar constraints to HTML, such as SVG, without them 
having to normatively reference the HTML5 spec), and those reasons 
should be considered on their own merits, without accessibility being 
part of the argument.

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

I don't see LC->WD->LC as a failure. It would be a failure if we 
announced LC and *didn't* get a lot of comments that led to substantive 
improvements in the spec (requiring it to go back to WD).

> One is an improvement on previous versions of HTML (including XHTML
> serialization and DOM). The other is a 2D Graphics API.

It's a 2D graphics API which only really makes sense for web browsers. 
As purely a graphics API it's a poor design: path transformation are a 
bit weird; there's very limited control over text drawing; you can't 
even draw dashed lines; and so on. Most applications should use APIs 
like Cairo or Quartz 2D instead.

It makes sense in web browsers because the web brings strong 
requirements for interoperability and portability, and has other 
influences on the design (e.g. text drawing is designed to work 
adequately even if a user doesn't have the font the author expected), 
and because most web browsers have already implemented it. So it would 
be sensible for SVG to use the existing canvas API, because it has 
similar requirements and it would benefit from the existing 
implementations. But I can't think of anywhere else it would be appropriate.

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

My email was about one reason, not all reasons. I don't think it's 
necessarily better kept in HTML5 - mostly I care about it being fairly 
stable, being extended with good API design, and being fixed properly in 
response to feedback on any problems, which I believe happens with the 
current process. It's fine if that will still happen with a separate 
document or new editors or in a new group.

-- 
Philip Taylor
pjt47@cam.ac.uk

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