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

On Jan 10, 2012, at 12:30 PM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai <ojan@chromium.org> wrote:
>> There are strong use-cases for both. In an app like Google Docs you
>> certainly want tab to act like indent. In a mail app, it's more of a
>> toss-up. In something like the Google+ sharing widget, you certainly want it
>> to maintain normal web tabbing behavior. Anecdotally, gmail has an internal
>> lab to enable document-like tabbing behavior and it is crazy popular. People
>> gush over it.
> 
> Hmm, good point.  Google Docs definitely wants tab to indent.

Would users press Esc to get out of the tab lock?



> 
>> We should make this configurable via execCommand:
>> document.execCommand("TabBehavior", false, bitmask);
> 
> I'm leery of global flags like that, because they mean that if you
> have two editors on the same page, they can interfere with each other
> unwittingly.  useCss/styleWithCss is bad enough; I've seen author code
> that just sets useCss or styleWithCss before every single command in
> case something changed it in between.
> 
> Could the author just intercept the keystroke and run
> document.execCommand("indent") themselves?  It's not as convenient, I
> admit.  Alternatively, perhaps the flag could be set per editing host
> somehow, and only function when that editing host has focus, although
> I'm not sure what API to use.
> 
>> The bitmask is because you might want a different set of behaviors:
>> -Tabbing in lists
>> -Tabbing in table cells
>> -Tabbing blockquotes
>> -Tab in none of the above insert a tab
>> -Tab in none of the above insert X spaces (X is controlled by the CSS
>> tab-size property?)
> 
> Bitmasks are bad -- many JavaScript authors don't understand binary
> well, if at all.  Also, what are use-cases where you'd want to toggle
> indentation in all these cases separately?  More complexity without
> supporting use-cases is a bad idea -- browsers have enough trouble
> being interoperable as it stands, and more complexity just makes it
> harder.
> 


I don't like these being called "tab", but, the use cases for standard navigation mechanisms for lists and grids make some sense.

-Charles

Received on Tuesday, 10 January 2012 21:48:59 UTC