The mission of the Web Events Working Group, part of the Rich Web Client Activity, is to provide methods to enable the use of a wide variety of input modes and devices, including multi-touch and pen-tablet input, game controllers, and mice.
|End date||31 October 2014|
|Confidentiality||Proceedings are public|
|Initial Chairs||Arthur Barstow (Nokia)|
Initial Team Contacts
(FTE %: 20)
|Usual Meeting Schedule||
Teleconferences: topic-specific calls may be held
Face-to-face: we will meet during the W3C's annual Technical Plenary week; an additional face-to-face meeting may be scheduled by consent of the participants
As increasingly advanced webapps are developed, the need to address input by a variety of user-interface modes and devices becomes more important.
Web browsers and mobile devices are making increasing use of touch-sensitive inputs, such as with a screen, trackpad, or tablet interface, as the primary or supplementary interface for web applications. This enables web developers to build more intuitive and sophisticated applications that fit naturally with the device being used. Touch interfaces have a long history going back to the 1960s, and faster, less expensive hardware and recent deployment on mobile devices have led to a proliferation of different approaches to software interface design. Touch interfaces frequently make use of custom gestures to signal user intent.
A related class of devices, including drawing tablets, interactive surfaces, pen devices, digital whiteboards, and spatial sensors, are also becoming more Web-enabled, driving the need to account for a wider range of capability than simple touch interfaces.
The aim of this group is to determine an appropriate set of functionality to standardize, and to define those features in way that may be deployed quickly, widely, and interoperably.
Touch events are simple, but may have characteristics different than mouse events, including pressure sensitivity. Pen tablets may add hovering and modal aspects to touch events. Multitouch events add yet another layer, allowing a user to use two or more fingers to accomplish a task, and may even permit multiple users to manipulate the user interface using the same input device, such as a screen input.
In addition to low-level direct input methods, the concept of representational events has emerged as a higher-level abstraction which may allow for device-independent inputs that map to touch inputs as well as more traditional mouse and keyboard inputs, allowing authors to express more intentionality and universal functionality. Authoring to such a wide variety of input devices, including various touch and pen-tablet devices, the traditional mouse and keyboard, as well as accessibility input devices, can be challenging; thus, a high-level set of abstracted events is useful in defining device-independent and user-interface-independent interactions. The may include task-specific events such as common editing commands.
There are four conceptual layers for touch and pen-tablet interactions: physical; gestural; representational; and intentional.
Finally, different devices may have associated metadata beyond the physical layer, such as modal information which should be available to content developers; for example, a tablet device may have multiple pens with different colors or brush styles associated with each. A method for the device to convey this to the application along with other event information is very desirable, and a generic metadata property should be defined to facilitate this in an extensible way that will allow for novel future device inputs.
The Web Events Working Group's deliverables include documenting appropriate use-cases and requirements, and a specification for events and APIs to enable low-level physical events and high-level representational events, which may describe some mapping between the two; for ease and clarity of authoring, the model should include a way to manage the complex relationship between mouse and low-level multi-touch events, and should include a generic metadata property for device-specific non-physical modalities.
Traditional pointer-device interaction involves moving the cursor on screen in response to user manipulation of the input device (e.g. moving the mouse). However, another common mode for mouse interaction, especially in gaming, is to use the mouse to change the viewport itself, rather than a cursor. This is an essential input mode for certain classes of applications, especially first-person-perspective 3D applications and 3D modeling software. The Mouse Lock API deliverable defines an API that provides scripted access to raw mouse movement data while locking the target of mouse events to a single element and removing the cursor from view.
This is a new deliverable, the Mouse Lock API.
Some user agents have connected gamepad devices (also known as joysticks), which can be used for games and other "10-foot" user interfaces (e.g. presentations, media viewers). Currently, the only way for a gamepad to be used as input for webapps is to emulate mouse or keyboard events; however, information is lost with this approach, and it requires additional emulation software outside of the user agent. This deliverable defines support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers.
This is a new deliverable, the Gamepad API.
The Working Group also intends to include guidelines for providing alternative interaction methods for people with disabilities—specifically those disabilities involving motor skills and vision; these guidelines should include both traditional interaction methods such as mouse/keyboard, game controllers, and interaction methods based on tactile feedback systems for touchscreens. These deliverables must apply to desktop and mobile browsers, and other non-browser environments where appropriate, and must be consistent with Web technologies designed in other working groups including WebApps, DAP, HTML, and SVG.
In order to get the broadest possible participation and quickest standardization of the physical and representational events that are currently missing from the Web platform, the normative definition of specific gesture events are out of scope for the Web Events Working Group at this time. A future charter may include normative gesture events as a deliverable, based on implementation and development experience.
Pen/stylus-tablet interactions have many different aspects; ink and handwriting APIs are related topics, but are outside the scope of this current charter. For digital ink representation, see the InkML specification.
There are many types of game controller, but the gamepad deliverable will deal only with traditional joysticks and button-based controllers with accelerometers, and excludes support for more complex devices that do camera-based motion sensing, depth sensing, video analysis, and gesture recognition.
In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each of feature defined in the specification.
The working group will deliver the following specifications. Touch Events version 1 and 2, and User Action Events have been split out from the originally chartered Web Events 1.0: Multitouch and User-Action Events specification, and the Mouse Lock API and Gamepad API specifications are new deliverables.
This is a new deliverable.
This is a new deliverable.
Other non-normative documents may be created such as:
|Note: The group will document significant changes from this initial schedule on the group home page.|
|Touch Events version 1||Feb 2011||Sept 2011||Dec 2011||Jun 2012||Aug 2012|
|Touch Events version 2||Jan 2012||August 2012||Nov 2012||May 2013||Sept 2013|
|Mouse Lock API||Jan 2012||August 2012||Nov 2012||May 2013||Sept 2013|
|Gamepad API||Jan 2012||August 2012||Nov 2012||May 2013||Sept 2013|
|User Action Events||Jan 2012||August 2012||Nov 2012||May 2013||Sept 2013|
To be successful, the Web Events Working Group is expected to have 10 or more active participants for its duration. The Chairs and specification Editors are expected to contribute one day per week towards the Working Group. There is no minimum requirement for other Participants.
The Web Applications Working Group will also allocate the necessary resources for building Test Suites for each specification.
The group encourages questions and comments on its public mailing lists, as described in Communication.
The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.
Most Web Events Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
Information about the group (deliverables, participants, teleconferences, etc.) is available from the Web Events Working Group home page.
The group will use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.
Information about the group (for example, details about deliverables, issues, actions, status, participants) will be available from the Web Events Working Group home page.
As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
This charter for the Web Events Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
$Date: 2011/10/25 20:11:41 $