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

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.

On Tue, Jan 10, 2012 at 7:28 PM, Ojan Vafai <ojan@chromium.org> wrote:
> 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.

What would be the behavior on Element?  Something like

* If the element is not an editing host, throw.
* For things like styleWithCSS, set the flag for that editing host and
its descendants only.
* For regular commands like bold, run the command restricted to the
descendants of that editing host.

Whereas calling it on document would affect all nodes in the document.
 This sounds like an interesting idea.  You're right that you don't
want the bold button for one editing host affecting other editing
hosts, which in my spec it currently does.

I've filed a bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15522

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

Current indentation behavior is here:

http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#indenting-and-outdenting

You're right that it doesn't match up with how tab works at all.  The
way I make other keystrokes work (Enter, Delete, etc.) is by mapping
them to some command, following WebKit:

http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#additional-requirements

So I need to define a tab command.  I've filed a bug:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15523

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

What are examples, and why?

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

Received on Wednesday, 11 January 2012 16:16:14 UTC