Re: [DOM3Events] Comments on DOM Level 3 key events

On 10/25/2012 10:33 AM, Hallvord Reiar Michaelsen Steen wrote:
>> Do other browser vendors have thoughts here?
> 
> 
> Trying to sum up some internal Opera discussion - hope I'm not mispresenting it, this isn't some "official" position either:
> 
> 
> We've been considering two models or concepts, some (internal JS authors) suggested that modifiers keys that have caused a transformation of the current character (as given by event.char) should not be included in the event object. In other words, the Q keypress in Shift-Q would have {char:'Q', shiftKey:false} because the char is already "transformed" by the shiftkey. I don't think this is backwards compatible with existing content though.
> 
> 
> I think there largely was an agreement that event.key should try to identify the "key" without any modifications or transforms caused by other keys or states. (This implies Opera is wrong to set event.key to 'Q' rather than 'q' in the Shift-Q keypress - personally I'd prefer {char:'Q', key:'q', shiftKey:true}). A mapping to the actual, un-modified "key" doesn't necessarily come "for free" on all platforms but on those that require extra work we have to do this work anyway, to set event.keyCode to what web content expects.
> 
> 
> For alphanumerical keys and named function keys, this seems pretty simple to implement, for punctuation and "OEM keys" it might be more hazy, but generally I believe we have to rely on what the OS says the key is. Opera already gets for example "?" on a Norwegian keyboad right - the question mark is the shiftet state of the + key in this keyboard layout, so we fire the keypress event with these details: { key:'Add', char:'?', shiftKey:true }.
> 
> 
> (On the other hand, we don't currently obey this proposed model for dead keys - striking the dead key for "umlaut", then o gives me a ö character as expected, but the keypress is {key:'ö',char:'ö'} rather than {key:'o', char:'ö'}.).
> 
> 
> I think the above is a reasonable interpretation of the spec's intentions (however I do also think the spec is too vague, if it was precise enough we would not be having this discussion).

So Opera would agree with Mozilla to have an attribute on the
KeyboardEvent interface that represents the physical key that has been
pressed?

However, I think we should use a new attribute instead of 'key'.
Otherwise, on my laptop, it would be hard to know what this would be doing:
{ char: '', key: 'Home' }
it could be the 'Home' key or the 'BrightnessUp' depending on my
pressing 'Fn' or not.

Generally speaking, as long as modifiers happen in keys without a char
representation, 'key' would be the only way to know what's the final
value so to know the actual physical key value, we will need a new
attribute.

Would that work for Opera?

Cheers,
--
Mounir

Received on Thursday, 25 October 2012 16:51:19 UTC