[DOM3Events] Action-375 Guiding Principles Thoughts

http://www.w3.org/2008/webapps/track/actions/375

As part of this action, I've taken two approaches to answer the question: what are the  guiding principles for event usage?


1.       Circumstances when an author would use an event

2.       Principles behind when a new feature should consider creating an event

#1 is a bit nebulous-but here's my take on it:

Authors should use events in scenarios where a web app needs to respond (take an action) in response to a user's action. Generally this happens in relation to user-input, either from directing a mouse at the web app, entering keys on a keyboard (or virtual input surface), voice commands, or other forms of input. Appropriate events have been created (or are defined by this specification) that allow authors to detect and respond to these user-inputs.

Other events exist that are designed to proactively notify the author when the state of the application changes. Such events are generally also related to user-inputs, such as a user first navigating to a page, which triggers parsing of HTML, which then triggers DOMContentLoaded (for example) to fire. Another example is the end-user navigating away from a web app (in user-agents where that scenario makes sense), where an unload event is triggered.

Another class of events act as "confirmation" events; they confirm that a state change occurred. Unlike the other events mentioned, these events may not originate from a user-action, but rather from an action taken by program code. Mutation events are such an example. Event types of this class exist not necessarily for the web app author, but rather for "extension" code written by third parties that does not have an intrinsic knowledge of the author's program code. Naturally, the web app author's program code knows (or should know?) the implications of running its code, therefore it has no need of "confirmation" events. However, extension code does not necessarily know all the implications of the program code that hosts it; yet it needs to be aware of document state and thus depends upon confirmation events to respond to changes and update its internal state. For this reason, confirmation events generally have a negative performance impact on a web app.

Web app authors should use events when responding to user-input as mentioned above. Additionally, authors of extension code (here meaning general-purpose program code written to be hosted inside of a web app) may make use of confirmation events to track and respond to document state changes.

#2 is highly correlated with the first principle:

This specification (or future event specifications) should define events for common scenarios taken by end-users when interacting with a web app. Such events should include (but not be limited to): mouse interaction, keyboard (and virtual keyboard) interaction, voice interaction, touch interaction, etc. Convenience events should also be specified which allow a web application to respond to common user actions within the categories previously listed. Such convenience events include, for example: reset events (for button clicks on a reset form button), focus and blur events, zoom events, editing events.

This specification may also include "confirmation" events as described earlier. Care should be taken to ensure that confirmation events are specified in a way that ensures that they can be triggered in a scoped, performance-neutral way. Note that due to traditional event registration techniques (e.g., addEventListener), confirmation events in general may be better suited to a different registration model than other events.