Request for TAG review of Input events level 2

[triblondon]

Split from #160.

Hello TAG!

I'm requesting a TAG review of:

• Name: Input Events specification level 1/2
• Specification URL: https://rawgit.com/w3c/input-events/v1/ (level 1) and https://w3c.github.io/input-events/index.html (level 2)
• Explainer, Requirements Doc, or Example code: http://w3c.github.io/editing/ (includes explanation for why contenteditable as it exists today is problematic and why additions such as the beforeinput event are needed)
• Primary contacts: johanneswilm, choniong

We have both gone through the security review independently and have not been able to think of any new security issues that do not already exist (such as listening in on users typing passwords in various ways or reccording the typing pattern in order to recognize the user as he/she moves from site to site.)

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[triblondon]

We're prioritising Level 1 for the Tokyo F2F, so may not get to this issue this time around

[torgo]

Taken up at f2f... we note that the changes requested for level 1 have been made (great!). But we need to review level 2.

[dbaron]

See the diff between levels 1 and 2 (thanks respec!).

[dbaron]

Discussed in a breakout in today's TAG meeting. @travisleithead explained why this specification exists (to serve editing tools that want to do their own thing rather than relying on the browser editor behavior).

It's not clear that there's much architectural feedback we could give on the delta between these specifications, given that it's pretty small.

@hadleybeeman wonders if there should be an explanation somewhere of why there are two separate levels with relatively small differences. (@travisleithead believes it's because the parts in level 1 have 1 implementation, and the parts deferred to level 2 don't.)

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.

[johanneswilm]

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.

@hadleybeeman I assume you probably do not want us to put this entire explanation into the document. Would an explanation in the non-normative part of level 2 saying something like the following be enough? "Level 2 expands on level 1, specifying that beforeinput events not related to IME composition must be cancelable and adding extra events before and after IME input to allow for isolation of IME compositions."

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.

[cynthia]

Taken up at Nice F2F. @johanneswilm would it be possible to add an normative note that level 2 expects to obsolete level 1 when it goes through somewhere in the spec?

(This is mostly to reduce confusion, for web developers or implementors without the background on why the split happened and what can be ignored later on)

[travisleithead]

And the above explanation for the differences between the specs would be great to toss into an explainer doc (or spec intro section) :-)

[johanneswilm]

What do you mean by "expects to obsolete"? Currently we hope that level 1 will be obsolete once everyone adopts level 2. However, there is the chance that we won't ever agree, or that we end agreeing on level 3 rather than 2.

[johanneswilm]

Ok. Adding to explainer document is certainly possible!

[hadleybeeman]

@johanneswilm

What do you mean by "expects to obsolete"? Currently we hope that level 1 will be obsolete once everyone adopts level 2. However, there is the chance that we won't ever agree, or that we end agreeing on level 3 rather than 2.

We meant that level 2 expects to obsolete level 1. It clears up any potential implication that there might be architectural reasons/distinctions between levels 1 and 2 — when in fact they're mostly a description of the implementation order. Just keen to avoid confusion.

[travisleithead]

Ok. Adding to explainer document is certainly possible!

@johanneswilm looking forward to reading it! (Didn't see any changes to the explainer or L1/L2 specs yet when we looked on our call today ;)

[johanneswilm]

Right, my inaction was due to rapidly changing political circumstances around the specification. An opinion paper was recently launched by Alexandre Elias [1] which presents a very different view on much of this, and it is unclear to as of this date to what degree it represents the view of the Chromium team as a whole. Should this be the view of the entire Chromium team, then we will likely have to roll back expectations of finding consensus on level 2 or 3 of the spec. I have not been successful in getting a good answer to this, but I hope to obtain more information during TPAC.

I have added an explanation to the README.md [2] which is as much as we have of an explainer document of this. Is this what you meant by explainer document, or did you want it somewhere else?

[1] https://docs.google.com/document/d/10qltJUVg1-Rlnbjc6RH8WnngpJptMEj-tyrvIZBPSfY/edit

[2] https://github.com/w3c/input-events/blob/gh-pages/README.md

[travisleithead]

I suppose I was imagining the text integrated into the L2 spec itself, but thank you for putting it in the readme. I've heard of Alexandre's comments, and am also unclear on where that's coming from. Hope you got some clarity at TPAC.

[johanneswilm]

We did get clarity I think. If this is something you are interested in, I'll be happy to chat with you guys. In short, the document is more a summary of various ideas Alexandre had. The document has value in that it documents historic ideas existibg at one time, and it may in the future inspire new standards, but given there is currently no plan to make specs of all of it, so level 2 continues to be the current state of where the discussion has gone. Hopefully the Chromium yeam will be able to clarify soon whether they support it or propose an alternative.

[travisleithead]

@johanneswilm thanks for responding, and thanks for the added text in the readme. Other than the IME concerns by Alexandre, it looks like you've got a good start on this spec. As there's not that much new here to review besides those issues, we'll go ahead and close this split-off review. As new substantive changes come to Input Events Level 2, we would kindly ask you to open a new issue so that we can have a chance to review. It's been our pleasure, and we hope to hear from you again!