Re: [w3ctag/design-reviews] Request for TAG review of Input events level 2 (#173)

Level 1 has two implementations (Chrome and Safari) and level 2 has one (Safari). Level 2 is was what we we had spend years of discussions reaching, and it was only in the last minute that the Android, which had not been part of the discussions, team let us know that they would not implement certain parts of the specification related to IME. At this time Safari had already implemented the full specification. We also did not want to give up level 2 of the spec, because it actually resolves a lot of issues and there has been no counter-proposal to effectively solve these issues from the Android team or others. Given that Chrome told us that we either had to release a spec with their proposed changes or they would drop the spec entirely, we decided to split the specification in two levels. 

Even though the specs look somewhat similar, they have to be handled quite differently by JavaScript editors:

* Level 1 gives the JS editor information about proposed changes from the user, but it makes the related DOM change be non-cancelable in many cases. The event is therefore only useful in combination with a way to roll back the DOM after the DOM change has been made, most likely a DOM-diffing library. In the case of IME, it is extra difficult to handle as DOM changes cannot be reverted before the composition has finished.

* Level 2 gives the JS editor information information about the proposed changes from the user and let's the JS author cancel the changes the browser otherwise would have done. There is one exception to this and that is IME, which cannot be canceled due to various technical constraints, but events have been added before and after IME input that effectively allow the JS author to isolate IME input. A JS editor based on level 2 should therefore be implementable without including DOm-diffing libraries or rolling browser-made DOM-changes back. A test of trying to create an editor using the event was conducted by the CKEditor team a year ago.

> It seems like it's also worth continuing to be open to other approaches that may be more easily implementable for handling the IME interaction here.

So far, we have heard of no other proposals that will solve this. We have spent extensive amounts of time discussion it and so far this is the only solution we have been able to come up with. The current solution in level 2 was proposed by the Chrome team and implemented by Safari successfully. If there are counter-proposals of how to solve this, we would be very much interested in hearing about them. But we probably shouldn't remove a working solution without replacing it with an alternative solution as IME input is a major headache for JS authors.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/173#issuecomment-323281226