Handling user input (HTML)
Windows 8 touch language features a simple set of gestures such as tap for primary action, slide to pan or drag an object, and swipe for selection. The touch experience should always be consistent and responsive. Despite the simplicity and flexibility of the Windows 8 touch programming model, there still are a couple of important performance best practices for you to learn.
Use built in controls and views or CSS properties to pan and scale
We recommend using Windows Library for JavaScript and intrinsic HTML controls because they automatically follow the Windows 8 best-practices for touch interaction. The scrolling and zooming views provided by Windows 8 create highly responsive sliding and pinching.
To implement your own touch scroll and zoom behaviors in Windows Store apps using JavaScript, use these Cascading Style Sheets (CSS) properties, DOM attributes, and DOM events:
| API surface | CSS Properties | DOM Attributes | DOM Events |
|---|---|---|---|
| Scrolling | |||
| Zooming | msContentZoomFactor | mscontentzoom | |
| Both | msmanipulationstatechanged |
For the best scrolling and zooming performance, use CSS properties. (For more info about the CSS properties and guidelines for using them, see Responding to user interaction.)
When you set these CSS properties, the platform optimizes performance and resource allocation by using separate threads to handle the touch input. You might not benefit from this optimization when you handle the MSPointer or MSGesture events manually.
Choose MSPointer or MSGesture Events by scenarios and the performance
A pointer object represents a single, unique input contact (a PointerPoint) from an input device (such as a mouse, pen/stylus, a finger, or multiple fingers). In the case of multiple devices or multi-touch input, each contact is treated as a unique pointer. In Windows 8, this pointer data is handled through a unified input stack for mouse, pen/stylus, and touch devices. Use the pointer object to code for touch and get mouse and pen input for free. If you want to customize the user experience for a specific device, you can use device-specific properties to write code that device. The DOM pointer events follow the familiar pattern of DOM mouse events, with extensions for touch properties and interaction principles.
The basic DOM pointer events include mspointerdown, mspointermove, and mspointerup. You can also use MSGesture events to easily access the touch language. The DOM performs gesture recognition, and raises gesture events that you can handle with your code. Here are some of the events you can register for:
| DOM gesture event examples | |
|---|---|
| Static gesture events | |
| Manipulation gesture events |
A static gesture event triggers a specific action through touch interactions such as tap, double tap, press and tap, and hold gestures. You can use these gestures as a substitute for mouse events that involve similar actions. The user performs a specific predefined interaction that triggers a gesture, and after the interaction is completed, the system raises a gesture event.
The manipulation gesture events indicate an ongoing user interaction. The system raises manipulation gesture events when the user touches the element. The system continues to raise manipulation gesture events until the user lifts the finger from the manipulated element .
Choose static or manipulation gesture events based on your app's needs, but also consider their performance impact. If your app needs to provide a quick, custom response immediately when the user touches an element, handle the mspointerdown event or the related manipulation gesture event.
Don't use an input event, such as MSPointerMove, to render UI
Don't animate your UI in time with input events. For example, if you're creating a paint app, don't draw to the canvas each time an mspointermove event is raised because it will degrade the app's performance.
To get smooth animations and rendering, an app needs to render only at 30 frames per second (fps), which is the speed most monitors can render at. But most input events happen quicker than 30 fps (touch events can happen more than 100 times a second). If you render along with an input event, you're forcing the app to do more work than necessary.