Re: [editing] move all caret movement intention events from beforeinput to beforeselectionchange? (#73)

Moving the caret movement types to beforeselectionchange makes sense to me. That seems orthogonal to renaming the event though.

I don't think the renaming makes sense. As you say, we already have an input event. If we rename these, then every input will end up having to fire beforeEdit, edit *and* input in addition to whatever keyboard events need to fire. This is bad for performance and bad for authors (one more event type they need to learn). 

Also, Blink/WebKit implement <input> as a wrapper around contentEditable. IMO, that's a good thing and it's one that we should build on and encourage all browsers to move to. Conceptually, the end result should be that <input> is a shadow DOM wrapper around a contentEditable=events element.

I wasn't there on the second day of the F2F when this was discussed, but as I understand it the concerns are:
1. We don't want to issue beforeInput/input events with a "bold" editType on <input>
2. targetRange doesn't work on <input>.

I agree with those concerns, but would be happier solving them in a different way. The beforeInput/input events just shouldn't fire for <input> if the user hits ctrl+b, etc and targetRange should be null.

This fits into the platform layering model of <input> being a wrapper around contentEditable because conceptually:
1. The code that dispatches beforeInput/input for ctrl+b would be a feature of the code that implements contentEditable=typing on top of contentEditable=events 
2. The code that fills targetRange would know to leave it out for closed shadow roots (once we finally get those specced and implemented).

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/73#issuecomment-135036321