Re: specification of "legacy" key events

On May 8, 2008, at 2:14 AM, Hallvord R. M. Steen wrote:

>
> but when re-reading the E-mail what Oliver actually said is a bit  
> more complex than I managed to capture in the proposed spec.
>
> The most important point is that the keyCode of any keydown and  
> keypress event must be 229 if an IME is processing the input. Apart  
> from that there is some inconsistency -
>
> Firefox fires keydown and keypress for the *first* character - the  
> one that initiates IME processing. Then it fires no keydown/press/up  
> events until character conversion is confirmed in the IME (for  
> Japanese IME this is done by pressing enter and Firefox fires a  
> keyUp for the enter key).
>
> On the other hand, MSIE fires keydown and keyup events - keydown has  
> code 229 and keyup has the virtual key code normally associated with  
> the given key.
>
> Safari behaves like IE.
>
> Opera seems to fire an initial keydown and no more events - nearly  
> what Firefox does but without the keypress.
>
> IMHO, there is no strong use case for firing events while IME is  
> processing - AFAIK there is nothing the web app can do about the  
> input except confuse itself. Unless someone brings up use cases or  
> content that depends on what Safari&IE do I'd suggest we specify  
> something along the lines of what Firefox&Opera do. To be specific,  
> a keydown and a keypress with codes 229 initally and no events while  
> IME is handling input. Inserting the text might cause a keyup for  
> enter (if that IME uses enter to confirm input) and must cause a  
> textInput event.

We have had requests to fire some kind of identifiable event when  
typing occurs during IME processing for use cases like the following:

1) To resize an area based on user typing, even during IME entry (yes,  
this works right, the text is in the text field even when unconfirmed..
2) To have special keyboard shortcuts work in a text field even during  
IME entry.

We originally had the Firefox-like model and deliberately switched to  
the IE-like model to cater to use cases like this and because we  
believe it is more Web compatible.

As such, I would strongly argue for the IE/Safari model instead of the  
Firefox/Opera model.

Regards,
Maciej

Received on Thursday, 8 May 2008 09:41:51 UTC