- From: Ben Peters <Ben.Peters@microsoft.com>
- Date: Sat, 13 Dec 2014 05:58:22 +0000
- To: Katie Haritos-Shea GMAIL <ryladog@gmail.com>, "chaals@yandex-team.ru" <chaals@yandex-team.ru>, 'Simon Pieters' <simonp@opera.com>, 'Arthur Barstow' <art.barstow@gmail.com>, 'Tobie Langel' <tobie.langel@gmail.com>, "Frederico Knabben" <f.knabben@cksource.com>
- CC: 'public-editing-tf' <public-editing-tf@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-indie-ui@w3.org" <public-indie-ui@w3.org>, "public-html@w3.org" <public-html@w3.org>
You all have excellent points, thank you! Device Independent Events gets straight to the point, and I like that. Are there any objections to calling this concept Device Independent Events? My goal with "Responsive Input Events" was to encourage web developers to use them as part of the responsive design pattern, allowing sites to work regardless of device or input modality. But the point about not being tied to another concept is well taken. To answer the questions about the scope of this concept, I believe it can apply to more than just DOM L3 Input Events. At the moment, the use cases are Input and Selection, and there is talk of doing something related for Scrolling. This design pattern should cover any way a user interacts with a web page, and the goal should be to make such 'input' resilient to new devices or input types. But keep in mind that there is no desire to actually use this term in an API. It is a concept that we want to capture in an Explainer document so current and future efforts can follow and refer to the design pattern, and so web developers understand what we're trying to accomplish with beforeInput events and beforeSelectionChange events. The reason I want to have this broad conversation about naming is simply for consistency in terminology across relevant specs.
Received on Saturday, 13 December 2014 05:58:54 UTC