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

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

I knew your interest, but the topic line was still generally on Canvas
as a separate element, so I wanted to clarify splitting it off for
accessibility _wasn't_ the only argument. Having said this, I do feel
splitting it off to assist in incorporating accessibility is a valid
argument. There have been implementations of Canvas, true, but not
universally across all browsers. In fact, the majority of browser
market share does not have access to Canvas right now.

So now is the time to implement accessibility, when we're about to
formalize Canvas as a W3C specification, and potentially increase
browser market share that does implement Canvas.

Can this occur if Canvas is in HTML5? It can, but I don't think it's
optimal. For one, the focus of this group isn't 2D graphics, its a
group focused on improving HTML. We're already pulled in so many
directions that accessibility in Canvas won't get the attention it
deserves.

I think a group finetuned to an interest in Canvas, specifically, and
graphics, generally, would have a better idea of possible areas of
accessibility integration. At a minimum, they wouldn't have their
attention split across so many areas of interest.


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

OK, that's cool. Perhaps we need to start up separate threads for each.

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

I read the W3C process flow, and the hope really is that the document
progresses in a forward motion. It may not be a failure if it doesn't,
but it's not a success, or  something we want to depend on as a way to
"slip" in improvements.

Obviously, Canvas is not ready to move to LC. The solution is: pull it
out, and let it progress to LC is its time.

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

Sorry I didn't mean to imply pulling Canvas out for non-web purposes.
I don't see the W3C as being interested in non-web stuff.

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

But that's because we don't know the future. Regardless, we do know at
least two environments for Canvas: X/HTML and SVG. That's enough to
justify an independent spec.

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

Cool, so we agree in this regard, as long as there is a dedicated group.

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

Shelley

Received on Friday, 23 October 2009 16:23:39 UTC