Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements

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