Re: DOM Keyboard Event Level 3 questions about proposal

Егор Николаев <termi1uc1@gmail.com> skreiv Wed, 26 Sep 2012 11:09:20 +0200

> 1) How can I determine key combination triggering if user's locale is  
> other
> than US_en? Both 'char' and 'key' properties return the symbol, that's
> specific to current user's locale. For example how can we detect 'Ctrl+S'
> combination?

Hi,
this question has come up before (for example  
http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0000.html ) and the  
spec has no answer as of now.

You're quite correct that the spec touted as being better at I18N than the  
old ways of doing this, is actually worse - mainly due to this issue.

> if(event.key.toLowerCase() == 's' || event.key.toLowerCase() == 'ы' ||  
> ...
> [and so on for every locale that is supported by your web application.]
>
> 2) There's no clear statement about 'char' and 'key' values for special
> symbol key press events. Opera 12.10 x64 Win7x64  (12.10.1592 at least),
> for example, returns some gibberish in key and char property while Ctrl  
> key pressed. You can see it for yourself by going to
> http://h123.ru/-/tests/KeyboardEvent/ with Opera 12.10 beta RC and  
> pressing
> Ctrl+Q (or Ctrl+<any character>).

What Opera returns is the ASCII control character that key press would  
insert in a terminal window or something. It's implemented that way  
because the spec is somewhat unclear and there was no real discussion or  
consensus when I asked about this back in January.

What does IE9 do, BTW?

> 3) Why the 'key' property is case-sensitive if we already have 'char'
> property for input symbol detection.

Good question.

> To summarize I'd like to say that the new API doesn't solve any of the
> problems but creating new ones.

I've heard similar sentiments from other authors.

> Especially after cross-locales 'keyCode'
> property has been declared outdated.
>
> As a solution I'd like to suggest 'char' and 'key' logical division.  
> 'Char'
> property should return input symbol (just like it does right now) and  
> 'key'
> property should always, for any special symbol key pressed, return
> lowercased US_en locale symbol for any symbol value. For example it can  
> be:
> event :{
>   key : "q"
>   , char "Й"
>   , shiftKey : true
>   , locale : "RU_ru"
>   , ...
> }

Looks like a more author-friendly solution, though I don't know if it's  
possible to implement it. It presumably would take quite some work if we  
need some sort of conversion tables for all keyboard layouts to know what  
the corresponding US_en key is.. Or do we?

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Thursday, 27 September 2012 07:51:43 UTC