On 09/01/2010, at 1:22 AM, Mike Taylor wrote:
Can you be more specific about how this is broken, and in what
browsers?
It would also be most helpful if you linked to your previous message
Previous message was entitled "Key Event Handling", posted 17 Dec.
The code there was specific to Raphael. I posted a revised version
(though still with Raphael links - it was to demonstrate the logic) in
my response to the Event Filtering thread on Dec 6. I won't post it a
third time, but instead, explain the logic.
Keypress, keydown/up and textInput handling is broken in the
browsers.
jQuery makes that better AND WORSE. Please discuss.
If you want to reliably detect text input and special keys, including
auto-repeat for both, you need to jump through all kinds of hoops.
Most of the problems are with browser differences, but first...
jQuery issues with key handling:
1) jQuery populates "which" for browsers that don't provide it. This
causes some problems. For example, in Opera, you can't tell a left
arrow key from a single-quote without reference to the originalEvent,
where "which" = 0 for the arrow. You shouldn't have to do that.
2) There doesn't seem to be any support for DOM3's textInput event
yet. Or am I wrong, and some generic mechanism works for that?
To see why it matters, read on.
Browser issues with key handling:
To understand how the browsers are broken/different, you really need
to study <http://unixpapa.com/js/key.html> in detail - it's truly a
dog's
breakfast. I've worked through the minimum logic to meet my goals
above, and I'll walk through that here.
Keyup/keydown:
In Safari and MSIE, you get no keypress for non-text (special) keys.
That means you have to use keydown/keyup. If you dispatch on keydown,
you get a duplicate event on keypress for text input events.
That means you have to dispatch on keyup, or when an auto-repeated
keydown comes in, and to do that you need a variable to say which key
was already down.
This logic is still insufficient for some applications - for example,
it means
you don't see the Shift key until some other key follows, which makes
it hard to change a "move" to "copy" visual during a drag. So you need
special logic to dispatch modifier events during keydown (my example
lacks this; I didn't need it yet).
Keypress:
On keypress, you have several things to do:
a) Prevent the keyup handler dispatching a duplicate event
b) Look at originalEvent to make the Opera fix I mentioned
c) Handle the fact that Opera sets metaKey instead of ctrlKey
d) Always use "which" on MSIE, otherwise charCode
e) Use String.fromCharCode in (only) the correct cases.
The problem with fromCharCode is knowing when you should use it.
I regard an event as text input only in cases where a user would expect
to see a printable character inserted into a text field. So ctrl, meta
and
alt are special keys, not text input... or are they? There are all
kinds of
text input methods (IME's) and keyboards, and I'm sure that in some
environments (read, foreign languages and cultures) ctrl, alt and meta
should result in text input. Remember that some text input might result
from multiple consecutive keystrokes which should appear as special
keys, not text in their own right.
That's why DOM3 has introduced the textInput event. jQuery should
support the DOM3 event (where it exists) to help with I18N support.
It should provide support for bridging these other differences.
I'm not sufficiently immersed in the culture of JS and jQuery to make
a firm proposal as to how this all should be done, but I think it's
important that something gets done. I hope I've explained why.
Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
