Re: [editing] change of event names beforeInput -> beforeEdit -> beforeInput? (#87)

Removing "input" from contentEditable=true is not an option. There is a lot of content that depends on it.

The two options that are being considered are:
A. Fire beforeEdit/edit/input on all contentEditable elements and only fire input on textarea/input elements.
B. Fire beforeInput/input on all contentEditabe, textarea and input elements.

I feel strongly that we should do (B) since we already have the "input" event. I stated the detailed reasons in issue #73, but I'll summarize:

1. We should not have two events that are entirely redundant except for the fields on them ("edit" and "input"). This is both confusing for developers and has unnecessary performance overhead since some pages would have event handlers for both events.

2. We should not have different events for contentEditable/textarea/input. Conceptually, textarea/input should be a contentEditable inside a closed shadow DOM. In that world, some fields won't make sense (e.g. targetRanges) and will need to be null and some editTypes will simply never fire (e.g. ctrl+b won't fire an event because they are plain text). That's OK IMO.

@rniwa does option (B) sound OK to you?

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