Add beforeinput event #3165

Open
DannyJJK opened this Issue Feb 8, 2017 · 9 comments

Comments

Projects
None yet
8 participants
@DannyJJK

DannyJJK commented Feb 8, 2017

The beforeinput event has become supported by Safari 10.1:

https://developer.apple.com/library/prerelease/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_1.html

It'd be nice to keep track of what browsers support this as it could be a very useful event

@cvrebert

This comment has been minimized.

Show comment
Hide comment
@cvrebert

cvrebert Mar 25, 2017

Contributor

+1

Contributor

cvrebert commented Mar 25, 2017

+1

@cvrebert

This comment has been minimized.

Show comment
Hide comment
@jrunning

This comment has been minimized.

Show comment
Hide comment

+1

@js-choi

This comment has been minimized.

Show comment
Hide comment
@js-choi

js-choi Jan 13, 2018

+1.

The name of this specification, as @johanneswilm mentioned above, is Input Events. It should also be mentioned/linked in its existing entry for input event.

Furthermore, Input Events has two specification levels. Level 1 is already implemented by Chrome and Safari. Level 2 is already implemented only by Safari. The state of affairs is a bit complicated, as described below, and they thus should be documented in Can I Use:

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.

js-choi commented Jan 13, 2018

+1.

The name of this specification, as @johanneswilm mentioned above, is Input Events. It should also be mentioned/linked in its existing entry for input event.

Furthermore, Input Events has two specification levels. Level 1 is already implemented by Chrome and Safari. Level 2 is already implemented only by Safari. The state of affairs is a bit complicated, as described below, and they thus should be documented in Can I Use:

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.

@js-choi

This comment has been minimized.

Show comment
Hide comment
@js-choi

js-choi Feb 4, 2018

Mozilla Bug 970802 tracks Input Events (presumably at least Level 1) in Firefox. There has been some sporadic recent activity.

js-choi commented Feb 4, 2018

Mozilla Bug 970802 tracks Input Events (presumably at least Level 1) in Firefox. There has been some sporadic recent activity.

@lborgman

This comment has been minimized.

Show comment
Hide comment
@lborgman

lborgman Feb 5, 2018

Please don't forget "contenteditable".

lborgman commented Feb 5, 2018

Please don't forget "contenteditable".

@js-choi

This comment has been minimized.

Show comment
Hide comment
@js-choi

js-choi Feb 5, 2018

Yes, if a new entry for Input Events Level 1/2 and beforeinput were created, both the existing input event’s entry and contenteditable’s entry should link to it.

js-choi commented Feb 5, 2018

Yes, if a new entry for Input Events Level 1/2 and beforeinput were created, both the existing input event’s entry and contenteditable’s entry should link to it.

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