On Thu, Jan 14, 2010 at 9:54 AM, Erik Arvidsson <a...@google.com> wrote:
> Keyboard events in browsers has and is a compatibility nightmare. I
> feel like the current working draft for DOM level 3 Events is making
> good progress in cleaning this up and it is worth a read if you are
> planning to do anything related to keyboard events in a browser.
> http://www.w3.org/TR/DOM-Level-3-Events/
>
> Here are some random points based on your initial proposal.

Thanks.

I would far prefer to follow an existing standard rather than
re-invent the wheel here, and this spec looks very complete.  Would it
make sense for this method to simply take an object of type
keyboardEvent, as defined in the DOM level 3 event draft?  Do we
already have support for turning a keyboardEvent into a native event
on each platform, or is there a logical place to put such code?
Writing new keyboard event conversion code specifically for this
extension api seems like the wrong idea - I'd far prefer to tie this
to existing effort in Chrome or WebKit...

- Dominic

> - You also need 'meta' modifier support (meta maps to the command key on Mac).
> - You need to distinguish and allow both left and right modifier keys.
> This is important for things like Bidi switching and language
> switching
> - There needs to be some way to do keydown and keyup (as well as textInput)
> - Using keyIdentifier seems like the way to go.
> - You probably also need to support something similar to keyLocation
> (which covers left and right shift)
> - Also look at DOM textInput event which is the attempt to fix the
> keypress event and it handles things like IME and other methods for
> inputting text.
>
>
> erik
>
>
>
> On Thu, Jan 14, 2010 at 07:26, Dominic Mazzoni <dmazz...@google.com> wrote:
>> Hi Darin,
>>
>> Erik suggested you might have some thoughts. In my proposed extension
>> api for accessibility (http://codereview.chromium.org/402099) one of
>> the functions is to simulate a key press. How should the client
>> express the key they would like to press?  The current proposed
>> function prototype is:
>>
>>      {
>>        "name": "simulateKeyPress",
>>        "type": "function",
>>        "description": "Simulate pressing a key.",
>>        "parameters": [
>>          {
>>            "type": "object",
>>            "name": "keyInfo",
>>            "properties": {
>>              "key": {"type": "integer", "description": "The code of
>> the key to press, corresponding to event.keyCode."},
>>              "control": {"type": "boolean", "optional": true,
>> "description": "True if the control key is down."},
>>              "shift": {"type": "boolean", "optional": true,
>> "description": "True if the shift key is down."},
>>              "alt": {"type": "boolean", "optional": true,
>> "description": "True if the alt key is down."}
>>            }
>>          }
>>        ]
>>      }
>>
>> What do you think?  Should the key be a keyCode? A charCode?
>>
>> Should it be cross-platform, or should it match what would be returned
>> by an onKeyDown handler? Are those even mutually exclusive?
>>
>> My current thinking is: the symmetry of using the same key codes
>> returned by onKeyDown is appealing. Also, even though there are some
>> differences, the most common keys needed to automate the UI (tab,
>> enter, arrows, alphanumerics) are already consistent across platforms.
>>
>> Thanks,
>> - Dominic
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>    http://groups.google.com/group/chromium-dev
>>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev

Reply via email to