- From: Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>
- Date: Wed, 9 Mar 2016 14:29:26 +0100
- To: Gary Kacmarcik (Кошмарчик) <garykac@chromium.org>
- Cc: Johannes Wilm <johannes@fiduswriter.org>, WebApps WG <public-webapps@w3.org>
On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик) <garykac@chromium.org> wrote: > Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will > receive a 'beforeinput' event just before any DOM update (with an option to > cancel it), and you'll also receive an 'input' event just after the DOM was > updated. If you want to track all DOM updates, then you only need to listen > to these two events. In my personal (and humble) opinion it's not actually a benefit for developers to have only one event that will fire a lot and indicate lots of different things. I accept that library authors want a convenient "point of overview" regarding what happens in the DOM (but wasn't mutation observers supposed to do that job?). However, making one single event type carry lots of different information and adding stuff like clipboardData and/or dataTransfer (because drag-and-drop changes the DOM too, right?) to the InputEvent interface seems like we force authors to 1) Write code with lots of if(e.eventType === foo) and switch(e.eventType) branching, which is hard to read 2) Debug code that gets run a lot all the time - event loops that fire often are annoying when debugging My five cents.. -Hallvord
Received on Wednesday, 9 March 2016 13:30:28 UTC