Re: [w3ctag/design-reviews] Request for TAG review of Input Events level 1 (#160)

The conversation from today extended regarding `onbeforeinput` for `<input>`, `<textarea>`, etc.

In the past I've had to write similarly hacky solutions for fixing up copy/paste/drop/etc. input for those other input types as is discussed here for `contenteditable` elements. One can argue that the `oninput` and `onchange` events allow this behavior, but for the same reasons that it's difficult to fixup content in `contenteditable`, other input types should have `onbeforeinput`. Similarly, it seems reasonable for `oninput` and `onchange` to be fired on `contenteditable` elements.

All of this is unsatisfying because it's a patch for forms and input elements is to break out (and make pluggable) the implicit controllers, models, and views that sit behind all of our input types. It's important for us to get these events exposed while that larger architectural issue is sorted out, tho.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/160#issuecomment-298142881