Fire "input" events as composed

[domenic]

This is how things have been implemented in all browsers, probably based
off of the definitions in the UI Events specification. See also the
discussion in #5453.

This includes an editorial change to deduplicate some repeated text in
the section.

• At least two implementers are interested (and none opposed):
  • All implementations behave this way.
• Tests are written and can be reviewed and commented upon at:
  • Add tests for input and change event properties web-platform-tests/wpt#24995 tests the main-line cases covered here. It doesn't test some of the more complicated input types, and it doesn't test the input events fired when the user changes their typing direction. But, it seems like reasonable coverage.
• Implementation bugs are filed:
  • Chrome: N/A
  • Firefox: N/A
  • Safari: N/A

(See WHATWG Working Mode: Changes for more details.)

---

/form-elements.html ( diff )
/infrastructure.html ( diff )
/input.html ( diff )

[annevk]

This seems fine. We might want to abstract this into a "fire an input event" thingie. When looking into this I noticed that we don't use the InputEvent class either, yet that is what both Chrome and Firefox implement. So it definitely seems like UI Events is being followed for things it doesn't really specify.