[whatwg] keyboard behaviour inside of editable area

[Alexander Surkov]

Hi.

My suggestion concerns to keyboard behaviour inside of editable area
(@contenteditable="true") within control elements. The suggestion is
based on Rich Schwerdtfeger comment from
http://lists.w3.org/Archives/Public/wai-xtech/2009Jul/0184.html:

> Form elements should operate the same way they do inside or outside the contenteditable area with one possible exception. I believe that if you are editing a contenteditable area and using the
> arrow keys and run across this situation
>
> text <input type="text">
>
> Then the right arrow key should when on the last t in text should move you into the text input field and arrowing to the right within it should arrow you out of the text field to the next dom node
> within the contenteditable area. A select might operate slightly differently when you drop the listbox down (probably want to cycle around the listbox while it is dropped. After all, you are editing
> a document. Up and down arrow keys should navigate you in and out of the form element based on its visual location.

The suggestion is to treat control element as special character, i.e.
when you move through the text by arrow keys and control element is
met then control element should be focused and its selection should be
changed appropriately. When control has the focus then keyboard
behaviour is defined by control preferences with once exception. If
particular navigation key isn't processed by control or doesn't have
any defined action then editor rules are applied. Let's consider
Rich's example:

begin<input type="text" value="text">end

If the caret selection is immediately after "begin" and right arrow
key is pressed then html:input is focused and its caret position is
set to the begin of text (after 't' of the 'text'). Once html:input is
focused then keyboard navigation rules for html:input are applied.
When the end of the text of html:input is reached then keyboard
navigation rules of editor are applied so that html:input looses the
focus and caret is moved to the 'n' character of the 'end' word. The
same rules are applied for up and down array keys inside of
html:input. If we deal with html:select at size>1 then html:select is
focused and arrow keys are used to move though select options. As well
if the first or the last option is achieved by up/down arrow keys then
html:select is unfocused and caret is set above/below the select
control.

The same idea is applied to the tab key. If control element is focused
then tab should focus the next control element. If the caret is on
text then tab key should do the action defined for the editor (for
example insert \t symbol). The idea to focus control element on
navigation keys makes control elements accessible by keyboard.

If editable area contains couple of control elements following each
other like "start<input/><select><option>1</option><button>finish"
then the combination of controls should be treated as word. Therefore
if you press ctrl+right arrow key (assuming the caret is after "start"
word) then focus should be moved to the next text entry (i.e. on
"finish" text).

I appreciate to hear your opinions and feedback.

Thank you a lot.
Alex.