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
e817f03785