e817f03785
L.Browser.touch is sometimes nice, but it's ultimately a flawed concept to use it for input events. Using L.Browser.touch for input handicaps people with mice if it's too liberal in what it classes as touchscreens, and handicaps people with touchscreens if it's too conservative. There's also no sweet spot: it's impossible to choose correctly if someone is using both a touchscreen and a pointer device, as there's no right option! Previously many of our event handlers and some of our UI was gated behind L.Browser.touch. This commit adds a new "window.touch" property which is used instead. It has functions to help with event detection, allowing you to easily make event handlers that work for only the input devices they are designed for, without gating them behind feature detection. This has the added bonus that - as you register all the events - switching between a touchscreen and pointer is now not only possible but already implemented! For cases which don't have reasonable events to tag onto (e.g. the teardrop for cursor movement) this commit adds "hasPrimaryTouchscreen" and "hasAnyTouchscreen" which use the CSS media queries to detect if there's a touchscreen attached to your device (either as the primary input mechanism or at all). This works a lot more similarly to L.Browser.mode, but being dynamically updated allows you to effectively swich between touchscreen and not at-will. This still has all of the disadvantages that L.Browser.touch did when used to register event handlers, so my advice would be to avoid using it with events. Signed-off-by: Skyler Grey <skyler.grey@collabora.com> Change-Id: I9016fc15ad3ccb3664af348fdcdca006495b0778 |
||
|---|---|---|
| .. | ||
| calc_helper.js | ||
| contenteditable_helper.js | ||
| desktop_helper.js | ||
| helper.js | ||
| impress_helper.js | ||
| interference_user_spec.js | ||
| mobile_helper.js | ||
| nextcloud_helper.js | ||
| repair_document_helper.js | ||
| search_helper.js | ||
| writer_helper.js | ||