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

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.

> 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.

Received on Tuesday, 10 January 2012 20:31:43 UTC