W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

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

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 6 Jan 2012 19:12:50 -0800
Message-ID: <CANMdWTu-u-ataYmi5BHL76vMT_mag8KbT41HWy5d1HWUi3cxCA@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: WebApps WG <public-webapps@w3.org>
BCC: whatwg, CC:public-webapps since discussion of the editing spec has
moved

On Tue, Jun 14, 2011 at 12:54 PM, Aryeh Gregor <Simetrical+w3c@gmail.com>wrote:

> You suggest that the tab key in browsers should act like indent, as in
>
dedicated text editors.  This isn't tenable -- it means that if you're
> using Tab to cycle through focusable elements on the page, as soon as
> it hits a contenteditable area it will get stuck and start doing
> something different.  No current browser does this, for good reason.
>

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.

We should make this configurable via execCommand:
document.execCommand("TabBehavior", false, bitmask);

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?)

Ojan
Received on Saturday, 7 January 2012 03:13:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT