Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input Events Level 1 and 2 #4003

Open
js-choi opened this issue Jan 12, 2018 · 1 comment
Open

Input Events Level 1 and 2 #4003

js-choi opened this issue Jan 12, 2018 · 1 comment

Comments

@js-choi
Copy link

js-choi commented Jan 12, 2018

The W3C Input Events specification allows authors to check and override the behavior of beforeinput and input events both before and after editing occurs. Several months ago, Wenson Hsieh of WebKit wrote a blog post and a demo that currently works in Safari TF only.

There are two specification levels. Level 1 is already implemented by Chrome and Safari. Level 2 is already implemented only by Safari. Copying from its readme:

Level 1 has two implementations (Chrome and Safari) and level 2 has one (Safari). Level 2 corresponds to the consensus reached within the Editing Taskforce at the end of 2016. Level 1 is a subset that was split off in early 2017, when the Chromium team announced that it would not implement the entire specifition. 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 Chromium team told the Editing Taskforce that it either had to release a spec with their proposed changes or they would drop the spec entirely, it was 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 in the second half of 2016 before it was implemented in browsers.

This state of affairs should be documented in Can I Use, and it should also be mentioned/linked in its existing entry for input event.

@cvrebert
Copy link
Contributor

Overlaps with #3165

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants