Wie kann ich nach Touch-Events testen, wenn Chrome Standardtests nicht besteht?

Question

habe ich auf

var supportsTouch = 'ontouchstart' in document; 

testen für Touch-Unterstützung für mobile und Desktop-Browser verlassen. Basierend auf diesem Test binde ich EventListener an Click- oder Touch-Events. Dies funktioniert in ALLEN aktuellen Browser-Versionen, aber das letzte Update auf Chrome Canary (24.0.1275.0 canary) und natürlich die DEV-Version schlagen diesen Test fehl.

Ich überprüfte den aktuellen moderniszr Test, aber das gibt auch ein falsches positives zurück, was bedeutet, dass Chrome unterstützt, obwohl die Funktion deaktiviert ist.

Meine aktuelle Problemumgehung besteht darin, zuerst für alle Arten von mobilen Browsern zu testen, und nur dann, wenn diese Ergebnisse positiv sind, den obigen Test zu verwenden, um auf Berührung zu prüfen. Der Nachteil ist, dass Sie die praktische Option "Touch-Ereignisse emulieren" in den dev-Tools von Chrome nicht verwenden können. Ideen?

Answer 1

Kurze Antwort: Ihr Test wird jetzt in jedem aktuellen Chrome wieder funktionieren. Aber wahrscheinlich nicht für immer.

Lange Antwort:

Die Chrome-Team wollte Touch-Ereignisse in Desktop-Browser an, wegen der wachsenden Zahl von Desktops mit Touch-fähigen Bildschirmen. So taten sie - wahrscheinlich um die Zeit von 24.0 Canary. Sie stellten dann fest, dass viele Leute taten, was Sie tun, um "Touch-Geräte" zu erkennen. Das Problem dabei ist Sie testen nur, wenn der Browser Touch-Ereignisse unterstützt, nicht das Gerät (gleiche gilt für Modernizr.touch). Genauer gesagt, nur die W3C/Apple TouchEvents API.

Sie wollten nicht verschiedene Versionen von Chrome für Touch/Non-Touch versenden, also haben sie es so gemacht, dass sie nur die Touch-APIs aktivieren, wenn sie beim Start ein Touch-Gerät entdecken (hier diskutiert: http://code.google.com/p/chromium/issues/detail?id=152149).

Jetzt wird Ihr Test wieder funktionieren ... ABER - wenn Sie sich selbst zukunftssicher machen möchten, möchten Sie vielleicht Ihren Ansatz ändern. Hier ist warum:

1. Nicht alle Browser führen diesen Schalter, dass Chrome tut.

2. Touch-Fähigkeit wird zu einem dynamischen Feature: Mit Microsoft Surface usw. können Sie von Tastatur und Maus trennen und Touch-only, Benutzer haben möglicherweise Touch-Monitore über KVM-Switches, die beim Start nicht erkannt werden, etc. Browser-Anbieter möchten nicht, dass APIs erscheinen und verschwinden - das wäre ein Albtraum - an einem bestimmten Punkt werden die Chrome-Leute die TouchEvents-APIs wahrscheinlich dauerhaft auf allen Geräten aktivieren. Dieser Test wird wieder "falsch positive" werfen.

Stattdessen sehen Sie die PointerEvents API, die eine gemeinsame Veranstaltung Schnittstelle für Maus, Touch und Stift Eingänge gibt. Wenn Sie machen Tasten größere Touch-Interfaces usw. denken, gibt es eine pointer media query spec zu (und ein hover eins), die bald in Browsern angezeigt wird - dies unterscheidet zwischen verschiedenen Genauigkeiten von Eingabegeräten - none/coarse/fine - Wenn Sie dynamisch sind, können Sie Ihre Stile auf der Grundlage der verbundenen Zeigergeräte anpassen, wenn diese verbunden/getrennt sind.Sehr cool.

Modernizr v3.0 (innerhalb der nächsten Wochen fallen) wird hier ein paar relevante Veränderungen haben:

• A erkennen für die PointerEvents API hinzugefügt wird
• Modernizr.touch wird Modernizr.touchevents besser umbenannt darstellen, was es bedeutet

Also würde ich, wenn verfügbar mit PointerEvents betrachten (die es bereits in IE10 ist), zurück zu einem Modernizr.touchevents Schalter fallen, wenn nicht.