- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 11 Jan 2012 12:09:19 -0800
- To: Aryeh Gregor <ayg@aryeh.name>
- CC: Ojan Vafai <ojan@chromium.org>, WebApps WG <public-webapps@w3.org>
On 1/11/2012 8:15 AM, Aryeh Gregor wrote: > On Tue, Jan 10, 2012 at 4:48 PM, Charles Pritchard<chuck@jumis.com> wrote: >> Would users press Esc to get out of the tab lock? > Do they need to be able to get out of it? They can't in a regular > word processor, so why should they be able to in Google Docs? If some > users need to be able to override the feature, that's a good reason to > have it supported by browsers, so browsers can override it. If the > page just intercepts tab, you can't get around it. The reason is listed in WCAG2 section 2.1.2 and CR5. http://www.w3.org/TR/WCAG/ The items suggest that a standard means of moving focus be maintained. Users should be given simple instructions on how to move focus if the keyboard is trapped. When the tab key is trapped, I recommend having the escape key move focus and untrap tab. That said, that can interfere with full screen mode, which may also use escape with varying success. > On Tue, Jan 10, 2012 at 7:28 PM, Ojan Vafai<ojan@chromium.org> wrote: >> Historically, one of my biggest frustrations with contentEditable is that >> you have to take it all or none. The lack of configurability is frustrating >> as a developer. Maybe the solution is to come up with a lower level set of >> editing primitives in place of contentEditable instead of trying to extend >> it though. > Yes, that's definitely something we need to do. There are algorithms > I've defined that would probably be really useful to web authors, like > "wrap a list of nodes" or some version of "set the value of the > selection" (= inline formatting algorithm). I've been holding off on > exposing these to authors because I don't know if these algorithms are > correct yet, and I don't want implementers jumping the gun and > exposing them before using them internally so they're well-tested. I > expect they'll need to be refactored a bunch once implementers try > actually reimplementing their editing commands in terms of them, and > don't want to break them for authors when that happens. We look to contentEditable as a means of programming and testing RTE. In "theory", we can implement RTE through the scripting environment, expose a feature-full execCommand set, and simply bolt-on existing editors such as the CKEditor. Author implemented RTE is a bit taboo, but it's quite useful in prototyping and developing authoring tools. Aryeh, your work on contentEditable is quite valuable, as it gives us a standard means to expose functions and a spec to follow. I understand and appreciate your careful deliberation. -Charles
Received on Wednesday, 11 January 2012 20:16:24 UTC