[whatwg] keyboard behaviour inside of editable area

[Alexander Surkov]

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 <timeless at gmail.com> wrote:
> On Mon, Oct 12, 2009 at 10:04 AM, Ian Hickson <ian at hixie.ch> 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 <shift> 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 <select> to add/remove/change
> items?
>