- From: Simon Sarris <simon.sarris@gmail.com>
- Date: Tue, 7 Feb 2012 17:02:00 -0500
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby <rubys@intertwingly.net>, public-html-a11y@w3.org, public-canvas-api@w3.org, Frank Olivier <Frank.Olivier@microsoft.com>, cyns@exchange.microsoft.com, jbrewer@w3.org, david.bolter@gmail.com, chuck@jumis.com, Philippe Le Hegaret <plh@w3.org>, mike@w3.org
- Message-ID: <CAA5isUaGUB-qGtVMq=1z_NXiVjJtaA60kM9VXaWUJQL2VDBLRw@mail.gmail.com>
I'm not sure that just because LibreOffice is making this that such features should be accommodated. LibreOffice has already gone a long way to forfeiting accessibility merely by choosing Canvas (see the list below for examples). They're not the first to try such an editor. The Mozilla Bespin (web IDE) project became Mozilla Skywriter became "forget it, we shouldn't have used HTML5 Canvas as a text editor" and merged with Ace, which uses plain old divs and not Canvas. It's not glamorous. But it's sane. (http://ace.ajax.org ) The Canvas spec already has an entire section devoted to why making a complex text editor rendered in Canvas is a bad idea, almost all of it relates to accessibility nightmares: * Mouse placement of the caret has to be reimplemented. * Keyboard movement of the caret has to be reimplemented (possibly across lines, for multiline text input). * Scrolling of the text field has to be implemented (horizontally for long lines, vertically for multiline input). * Native features such as copy-and-paste have to be reimplemented. * Native features such as spell-checking have to be reimplemented. * Native features such as drag-and-drop have to be reimplemented. * Native features such as page-wide text search have to be reimplemented. * Native features specific to the user, for example custom text services, have to be reimplemented. * This is close to impossible since each user might have different services installed, and there is an unbounded set of possible such services. * Bidirectional text editing has to be reimplemented. * For multiline text editing, line wrapping has to be implemented for all relevant languages. * Text selection has to be reimplemented. * Dragging of bidirectional text selections has to be reimplemented. * Platform-native keyboard shortcuts have to be reimplemented. * Platform-native input method editors (IMEs) have to be reimplemented. * Undo and redo functionality has to be reimplemented. * Accessibility features such as magnification following the caret or selection have to be reimplemented. Just food for thought. On Tue, Feb 7, 2012 at 4:47 PM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote: > Paul, Sam, > > You should consider reverting your vacated decision on canvas > caret/selection processing. > > libreoffice now provides a full office suite, including rich text editing > using HTML 5 canvas: > > http://listarchives.libreoffice.org/global/design/msg03226.html > > Note: I had nothing to do with this email post but it certainly highlights > the problem the decision to vacate created. I also do not know the person > who made the post. > > I should also note that the statements by some browser manufacturers that > you could not do an IME with Canvas was also inaccurate: Look at the broad > range of languages it supports: http://www.libreoffice.org/download/ > You should also mention that Google Docs also does not use > contenteditable. So, they also had to create their own IME. > > The vacated decision has broken canvas accessibility efforts leaving > libreoffice without a vehicle to address its accessibility. > > I hate to be right but I have been working on this stuff for 20 years. > Canvas is very close to what Windows application developers are used to. It > is logical that they would use canvas for this. This will be more pervasive > than you think. > > At this point I see no reason to submit a new change proposal. You have > the one we submitted previously. > > Rich > > > Rich Schwerdtfeger >
Received on Wednesday, 8 February 2012 22:11:11 UTC