W3C home > Mailing lists > Public > public-html@w3.org > December 2011

Re: Request to re-open issue 131

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Fri, 16 Dec 2011 11:25:48 +0000
Message-ID: <CA+ri+V=-XMqhSoF_v-LRJNHLZENqr8Jf+SQ=MoO-a_ymBC7OdA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Sam Ruby <rubys@intertwingly.net>, david bolter <david.bolter@gmail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, chuck@jumis.com, Cynthia Shelly <cyns@microsoft.com>, dbolter@mozilla.com, franko@microsoft.com, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
Hi Jonas

you wrote:
"I am personally not at all interested in implementing APIs that are
there solely for building text editors in canvas."

Of the proposed APIs which do you consider are solely for building text editors?

focus management
caret and selection management
extensions to text metrics
hit testing


On 14 December 2011 22:02, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Dec 14, 2011 at 10:31 AM, Sam Ruby <rubys@intertwingly.net> wrote:
>>> At Mozilla there are certainly voices for avoiding any kind of
>>> encouragement of canvas-for-text-app usage.
>> It would be helpful if those voices were to participate here, on
>> public-html.
> I am one of those voices.
> I am personally not at all interested in implementing APIs that are
> there solely for building text editors in canvas. I simply don't think
> that people can build good accessible text editors in canvas. Sure, we
> can slap a few APIs on there to improve certain aspects of it, but I
> don't believe anyone has ever proposed an API which will allow a
> *good* text editor to be written.
> I feel like people freaked out when they saw the demo-ware bespin
> using a canvas-based editor. However since then the bespin (now cloud
> writer) developers realized that creating a canvas-based editor was
> simply too much work and so they switched away from using canvas. The
> result was a more accessible user experience.
> In other words, the set of accessibility APIs that we have *now*
> deployed in canvas (i.e. basically none) lead the developers to create
> a more accessible editing experience than if they would have used the
> APIs suggested so far.
> In short, so far I'm not at all convinced that trying come up with
> APIs that are solely for enabling text editors in canvas is worth our
> or implementors time.
> This doesn't say anything about providing other accessibility-related
> APIs for canvas though of course. For things like text selection and
> hit testing I've seen more evidence both that we can create reasonable
> experiences using various proposed APIs, as well as more of a need due
> to how people use canvas on the web today.
> / Jonas

with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
HTML5: Techniques for providing useful text alternatives -
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Friday, 16 December 2011 11:26:41 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:46 UTC