Re: [w3c/uievents] Event order between "compositionend" and "input" (#202)

> Yes, sorry, by FF code I meant Firefox front-end code, i.e. the JS used for the FF user interface. While it's not entirely representative of typical Web content, for the purposes of handling input events I think it's reasonably close.

Firefox's front-end is one of the biggest web-applications in the world even though it uses some special API to access sensitive area. So, I believe that if some spec changes make Firefox's front-end more complicated, that means that web apps in the world are also made complicated if they need to implement similar feature.



>> Does the final beforeinput event need to have isComposing set in the same manner? My instinct is "yes, it should", but I'm open to arguments why is doesn't need to be.
>
> @masayuki-nakano what do you think about this? ↑

Honestly, I'm still not sure, I'm still thinking this...

>From a point of view of web browser, browser has not been handled native commit event yet at dispatching `beforeinput` event. I.e., there is a composition in the editor. So, setting false to isComposing of `beforeinput` may make sense.

On the other hand, `beforeinput` is not useful event if there were no `inputType` attribute value since web apps cannot know what will happen without the attribute. So, in other words, I have no idea how web apps use **only** `isComposing` information of `beforeinput`.

So, most important thing is, which value can prevent bugs of web apps...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/202#issuecomment-413454900