Re: [whatwg] keyboard behaviour inside of editable area
Hi, Josh. If I get right HTML5 assumes to treat HTML controls inside of editable area as normal controls. Therefore it's really helpful to know how much special mobile platforms might want to treat controls in editable area. I agree editor behaviour on user input should be defined by platform. However I wouldn't agree it should be browser-dependent. Starting from the point HTML controls inside of editable area are normal controls I just want to ensure these controls are accessible, partially it means they should be operable by keyboard because it's primary tool for assistive technologies users. Shortly all I suggest is to use editor's keyboard navigation rules if caret is on text or use control's keyboard navigation rules if control is focused, also I tried to define rules to make focus transition from editor to control. Therefore I don't touch BiDi behaviour because it's automatically addressed in this case. As well in this light arrow keys in my proposal are just an example to describe desired behaviour. It should be valid for Windows but another keys or ways might be required on another platforms. So my proposal is rather an idea than real proposal, an idea I like to discuss or get it approved. All of this is an attempt to produce general rules to ensure HTML controls are operable. Since controls inside of editable area are normal controls then it shouldn't be allowed to edit option labels (add or remove them), all you can do is to change the selected option. I can see a cases when it might be useful to have an ability to edit options. However I keep in mind default behaviour only. The default behaviour might be overridden by additional editor settings or web service directly to meet these needs. Thank you. Alex. On Tue, Oct 20, 2009 at 6:14 PM, timeless wrote: > On Mon, Oct 12, 2009 at 10:04 AM, Ian Hickson wrote: >> there's nothing that really requires that the >> user agent even support arrow keys, let alone that they work in a >> particular way. > > I believe MicroB, Fennec, and probably Mobile Safari will tend to > treat form controls as very special. > > I don't see any reason to specify this, as in reality, it's up to the > browser and platform to decide how such things should work. Ideally > the teams developing such platforms will evolve solutions which work > for their users. If they don't, I'd expect their users to act as > consumers and vote with their wallets/eyeballs (Sadly, that is > unlikely to be a good thing for MicroB). > > Of note, the N900 in most regional variants doesn't have up/down arrow > keys. And when people specify how arrow keys work in contentEditable, > i'd expect them to try to specify how arrow keys work while is > active (an attempt to influence selection length/shape). > > I've heard rumors that Qt has (plans?) for some magical way to control > position. > > Alexander Surkov's proposal also doesn't covered BiDi behavior > > Also, it's unclear to me what the goal is. Should I, as an end user of > an editable page, be able to edit a to add/remove/change > items? >
Re: [whatwg] keyboard behaviour inside of editable area
Hi, Ian. Thank you for the answer. AFAIK usually accessibility people tend to define kind of universal behaviour on mouse/keyboard interaction depending on OS of course. This case is probably not this one and behaviour should be implementation dependent. I'm not sure. Therefore I brought this issue for discussion. I'm happy you find the described behaviour reasonable. Thank you again. Alex. On Mon, Oct 12, 2009 at 3:04 PM, Ian Hickson wrote: > On Thu, 8 Oct 2009, Alexander Surkov wrote: >> >> 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. > > This seems reasonable (though I'd prefer to study it in a usability lab > before making a stronger statement), but it also seems like an > implementation detail -- there's nothing that really requires that the > user agent even support arrow keys, let alone that they work in a > particular way. > > Cheers, > -- > Ian Hickson U+1047E )\._.,--,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
[whatwg] keyboard behaviour inside of editable area
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 > > 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: beginend 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:sel...@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 "start1finish" 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.
[whatwg] HTML form controls inside of editable area
Hi. HTML 5 contentEditable section doesn't define behaviour of HTML form controls inside of editable area explicitly (http://dev.w3.org/html5/spec/Overview.html#user-editing-actions). The question is the following: is behaviour on keyboard or mouse interaction with form controls inside of editable the same like it is for form controls outside of editable area? So that for example if I click on HTML button inside of editable area then will button be clicked and onclick event handler be invoked? Or, for example, if HTML select is focused and I press down arrow key then will selected option be changed? It's obviously some keyboard shortcuts can have one meaning on focused HTML element and another meaning in editable area. It's necessary to define who wins. HTML 5 specification has words confirming implicitly the idea HTML form controls inside of editable area should preserve behaviour. These words are "When an editable form control is edited, the changes must be reflected in both its current value and its default value. for select elements it means updating the option elements' defaultSelected DOM attribute as well as the selected DOM attribute" which means user should be able to change selected option and therefore it's reasonable to expect form control behaves as usually. Can I get some clarification please? Thank you. Alex.
