- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 16 Dec 2011 11:25:48 +0000
- 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 http://dev.w3.org/html5/canvas-extensions/Overview.html#focus-management-1 caret and selection management http://dev.w3.org/html5/canvas-extensions/Overview.html#caret-and-selection-management extensions to text metrics http://dev.w3.org/html5/canvas-extensions/Overview.html#extension-to-the-textmetrics-interface hit testing http://www.w3.org/wiki/Canvas_hit_testing regards Stevef 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 | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Friday, 16 December 2011 11:26:37 UTC