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

On Tue, 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:
> > 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.
>

I agree the API is not the best. We should put execCommand, et. al. on
Element. That would solve the global flag thing for useCss/styleWithCss as
well. It's also more often what a website actually wants. They have a
toolbar associated with each editing host. They don't want a click on the
toolbar to modify content in a different editing host. This is a change we
should make regardless of what we decide for tabbing behavior IMO.

Calling indent doesn't actually match tabbing behavior (e.g. inserting a
tab/spaces or, in a table cell, going to the next cell), right? I guess
another way we could approach this is to add document.execCommand('Tab')
that does the text-editing tabbing behavior. I'd be OK with that (the
command name could probably be better).


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

The bitmask is not a great idea, but there are certainly editors that would
want tabbing in lists to work, but tab outside of lists to do the normal
web tabbing behavior. Maybe you're right that we should just have one
toggle though and if you want something more specific you do it in JS.

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.

Ojan