Re: html5 editor responds to Canvas accessibility related bugs

  On 10/3/2010 10:35 AM, Benjamin Hawkes-Lewis wrote:
> What we learn is that Bespin deployed "canvas" because:
>
>      1. Native controls don't have the required feature set.
>
>      2. "canvas" was more consistently implemented than SVG.
>
>      3. They got better performance rendering text with "canvas" than DOM.
>
> Including support for inline SVG in HTML5 is already fixing the second problem (see IE9); the critical question now involves speed.
>
> If we cannot give "textarea" the features authors and users want from "canvas"-based UIs, then it won't be used instead.
>
> If we cannot make the "contentEditable" DOM as fast as "canvas", then it won't be used instead.
>
> If the proposed accessibility APIs for "canvas" severely impact its performance, then they won't get used.
>
> So it would be nice to see some experimental implementations, or at least theoretical discussions, that address these critical feature and performance questions.
>

SVG support is not consistently implemented; IE9 will not have "fixed" 
the problem. Yes, there are still some critical issues involving speed 
with SVG. And by all means, yes, I'd like to see all of these elements 
improved. Still, comparing SVG to Canvas is like comparing apples to 
fructose.

I don't see how this all-or-nothing mindset is necessary: it's as though 
the canvas element is some foreign object misplaced in the w3c toolkit.

There are several text editors written using contentEditable in the 
wild, there are a handful of editors using canvas. There are editors 
using vanilla textarea. And there are a handful of SVG editors; written 
in SVG or in Flash. What kind of experimental implementations do you 
have in mind?

My interest in accessibility APIs for canvas is simply to report 
information where it's available. I've no difficulty, currently, making 
text larger, changing color schemes, nor providing alternate input 
methods. There are some twists though, in gathering that information, 
that I'd like to see standardized. Little to do with Canvas there. Most 
of the accessibility proposals need not be directed at canvas. Providing 
details about the position of the mouse cursor and focus area can still 
be useful for items outside of canvas, as a worthwhile extension to the 
concept of tabbed indexes.

It seems to me that we all share similar concerns about enabling 
accessibility, as well as improving the flexibility of the html+svg profile.

I don't understand why there is a stand being taken against the current 
use of canvas. We're not even discussing improvements on the tag, we're 
talking about existing usage, alive on the web today; and how two 
members here have come out saying that the existing usage is incorrect, 
a waste of time, or otherwise unwarranted. I'd love to get back to 
discussing improvements to the html+svg+canvas profile, but it's hard to 
do that here, without the good faith of editors and members.

As an off-topic: InkML is under-served. I've worked on an html+svg+inkml 
profile, using Canvas as a prototype. I've also used canvas to 
experiment with "textarea" features. The simple fact that it is used as 
a prototype, and is used in the wild, is reasonable evidence to acquit 
us canvas enthusiasts from wrong-doing.

-Charles

Received on Sunday, 3 October 2010 18:04:52 UTC