Interaktionsmedien-Features und ihr Potenzial (für falsche Annahmen)

Dies ist eine aktualisierte und stark erweiterte Version des vor 2015 auf dev.opera veröffentlichten Artikels. Dieser Artikel bezog sich auf den Editor's Draft vom 24. März 2015 der Spezifikation Media Queries Level 4 und enthielt ein ziemlich großes Missverständnis darüber, wie any-hover:none in der Praxis von Browsern ausgewertet werden würde.

Die Spezifikation wurde seitdem aktualisiert (einschließlich Klarstellungen und Beispiele, die ich nach der Veröffentlichung des ursprünglichen Artikels eingereicht habe). Diese aktualisierte Version entfernt daher die falschen Informationen des Originals und bringt die Erklärungen auf den neuesten Stand des aktuellen Arbeitsentwurfs. Sie deckt auch zusätzliche Aspekte im Zusammenhang mit der JavaScript-Erkennung von Touch/Eingaben ab.

Die Media Queries Level 4 Interaktionsmedien-Features — pointer, hover, any-pointer und any-hover — sollen es Websites ermöglichen, unterschiedliche Stile und Funktionalitäten (entweder CSS-spezifische Interaktivität wie :hover oder JavaScript-Verhalten, wenn über window.matchMedia abgefragt) basierend auf den spezifischen Merkmalen der Eingabegeräte eines Benutzers zu implementieren.

Obwohl sich die Spezifikation noch im Arbeitsentwurf befindet, werden Interaktionsmedien-Features im Allgemeinen gut unterstützt. Allerdings gibt es bis heute immer noch einige Probleme und Inkonsistenzen in den verschiedenen Browser-Implementierungen – siehe die aktuellen Testergebnisse für pointer/hover/any-pointer/any-hover mit Verweisen auf relevante Browser-Bugs.

Häufig genannte Anwendungsfälle für Interaktionsmedien-Features sind oft: „Steuerelemente größer/kleiner machen, je nachdem, ob der Benutzer ein Touchscreen-Gerät hat oder eine Maus/einen Stift verwendet“ und „ein CSS-Dropdown-Menü nur verwenden, wenn der Benutzer eine Eingabe hat, die Hover-basierte Interaktionen ermöglicht.“

@media (pointer: fine) {
  /* using a mouse or stylus - ok to use small buttons/controls */
}
@media (pointer: coarse) {
  /* using touch - make buttons and other "touch targets" bigger */
}
@media (hover: hover) {
  /* ok to use :hover-based menus */
}
@media (hover: none) {
  /* don't use :hover-based menus */
}

Es gibt auch Beispiele, bei denen Entwickler diese neuen Interaktionsmedien-Features nutzen, um standardbasierte „Touch-Erkennung“ zu erreichen, oft nur, um Touch-Ereignisse zu hören, wenn das Gerät als Gerät mit einem groben Zeiger identifiziert wird.

if (window.matchMedia && window.matchMedia("(pointer:coarse)").matches) {
  /* if the pointer is coarse, listen to touch events */
  target.addEventListener("touchstart", ...);
  // ...
} else {
  /* otherwise, listen to mouse and keyboard events */
  // ...
}

Diese Ansätze sind jedoch etwas naiv und entspringen einem Missverständnis dessen, wofür diese Interaktionsmedien-Abfragen konzipiert sind.

Was ist der primäre Input?

Eine der Einschränkungen von pointer und hover ist, dass sie per Design nur die Eigenschaften des vom Browser als primär eingestuften Zeigereingangs freigeben. Was der Browser denkt, und was ein Benutzer tatsächlich als seine primäre Eingabe verwendet, kann abweichen – insbesondere jetzt, wo die Grenzen zwischen Geräten und den von ihnen unterstützten Eingabetypen immer unschärfer werden.

Vorweg sei darauf hingewiesen, dass Interaktionsmedien-Features nur Zeigereingaben (Maus, Stift, Touchscreen) abdecken. Sie bieten keine Möglichkeit zu erkennen, ob die primäre Eingabe eines Benutzers eine Tastatur oder eine tastaturähnliche Schnittstelle wie ein Schalter ist. Theoretisch könnte ein Browser für einen Tastaturnutzer pointer: none melden, was signalisiert, dass die primäre Eingabe des Benutzers gar kein Zeiger ist. In der Praxis gibt es jedoch keinen Browser, der es Benutzern ermöglicht, anzugeben, dass sie tatsächlich Tastaturnutzer sind. Beachten Sie also, dass es unabhängig davon, was die Abfragen der Interaktionsmedien-Features ergeben, sinnvoll ist sicherzustellen, dass Ihre Website oder App auch für Tastaturnutzer funktioniert.

Traditionell könnten wir sagen, dass die primäre Eingabe eines Telefons oder Tablets der Touchscreen ist. Selbst auf diesen Geräten kann ein Benutzer jedoch eine zusätzliche Eingabe haben, wie z. B. eine gekoppelte Bluetooth-Maus (eine Funktion, die seit Jahren auf Android verfügbar ist, jetzt in iPadOS unterstützt wird und mit Sicherheit in iOS landen wird), die er als seine primäre Eingabe verwendet.

In diesem Fall, während das Gerät nominell über pointer: coarse und hover: none verfügt, verwenden Benutzer möglicherweise tatsächlich ein feinzeigendes Eingabegerät, das Hover-fähig ist. Ebenso, wenn ein Benutzer einen Stift hat (wie den Apple Pencil), kann seine primäre Eingabe immer noch als Touchscreen gemeldet werden, aber anstelle von pointer: coarse hat er nun eine Eingabe, die eine feine Zeigergenauigkeit bieten kann.

In diesen besonderen Szenarien, wenn die Website nur Schaltflächen und Steuerelemente vergrößert und Hover-basierte Interaktionen vermeidet, wäre dies kein großes Problem für den Benutzer: Trotz der Verwendung einer feinen und Hover-fähigen Maus oder eines feinen, aber immer noch nicht Hover-fähigen Stifts erhält er Stile und Funktionalitäten, die auf den groben, nicht Hover-fähigen Touchscreen abzielen.

Wenn die Website die Hinweise von pointer: coarse für drastischere Änderungen nutzt, wie z. B. nur noch Touch-Ereignisse zu hören, dann wird dies für Benutzer problematisch sein – siehe den Abschnitt über falsche Annahmen, die die Erfahrung komplett zunichtemachen können.

Betrachten Sie jedoch das Gegenteil: einen „normalen“ Desktop- oder Laptop-Computer mit Touchscreen, wie z. B. Microsoft Surface. In den meisten Fällen wird die primäre Eingabe das Trackpad/die Maus sein – mit pointer:fine und hover:hover –, aber der Benutzer verwendet möglicherweise den Touchscreen, der eine grobe Zeigergenauigkeit aufweist und keine Hover-Fähigkeit besitzt. Wenn Stile und Funktionalitäten dann speziell auf die Eigenschaften des Trackpads/der Maus zugeschnitten sind, kann es für den Benutzer problematisch oder unmöglich sein, den groben, nicht Hover-fähigen Touchscreen zu verwenden.

Merkmal	Touchscreen	Touchscreen + Maus	Desktop/Laptop	Desktop/Laptop + Touchscreen
pointer:coarse	true	true	false	false
pointer:fine	false	false	true	true
hover:none	true	true	false	false
hover:hover	false	false	true	true

Für einen ähnlichen Blickwinkel auf dieses Problem siehe „The Good & Bad of Level 4 Media Queries“ von Stu Cox. Obwohl er sich auf eine noch frühere Iteration der Spezifikation bezieht, die nur pointer und hover enthielt und die Anforderung, dass diese Features das am wenigsten fähige, anstatt das primäre, Eingabegerät melden.

Das Problem mit den ursprünglichen pointer und hover allein ist, dass sie keine Multi-Input-Szenarien berücksichtigen und sich darauf verlassen, dass der Browser in der Lage ist, ein einzelnes primäres Eingabegerät korrekt auszuwählen. Hier kommen any-pointer und any-hover ins Spiel.

Testen der Fähigkeiten aller Eingaben

Anstatt sich ausschließlich auf die primäre Zeigereingabe zu konzentrieren, geben any-pointer und any-hover die kombinierten Fähigkeiten aller verfügbaren Zeigereingaben wieder.

Um Multi-Input-Szenarien zu unterstützen, in denen verschiedene (Zeiger-basierte) Eingaben unterschiedliche Eigenschaften haben können, können mehr als einer der Werte für any-pointer (und theoretisch auch für any-hover, aber dieser Aspekt ist nutzlos, wie wir später sehen werden) übereinstimmen, wenn verschiedene Eingabegeräte unterschiedliche Eigenschaften haben< (im Vergleich zu pointer und hover, die sich immer nur auf die Fähigkeiten der primären Zeigereingabe beziehen). In aktuellen Implementierungen werden diese Medien-Features im Allgemeinen wie folgt ausgewertet:

Merkmal	Touchscreen	Touchscreen + Maus	Desktop/Laptop	Desktop/Laptop + Touchscreen
any-pointer:coarse	true	true	false	true
any-pointer:fine	false	true	true	true
any-hover:none	true	false	false	false
any-hover:hover	false	true	true	true

Wenn wir auf die ursprünglichen Anwendungsfälle für Interaktionsmedien-Features zurückkommen: Anstatt unsere Entscheidung, größere oder kleinere Eingaben bereitzustellen oder Hover-basierte Funktionalität nur basierend auf den Merkmalen der primären Zeigereingabe zu aktivieren, können wir diese Entscheidung basierend auf den Merkmalen irgendeiner verfügbaren Zeigereingabe treffen. Grob übersetzt, anstatt zu sagen „alle Steuerelemente vergrößern, wenn die primäre Eingabe pointer: coarse hat“ oder „ein CSS-Menü nur anbieten, wenn die primäre Eingabe hover: hover hat“, können wir Medienabfragen erstellen, die bedeuten: „Wenn eine der Zeigereingaben coarse ist, Steuerelemente vergrößern“ und „nur ein Hover-basiertes Menü anbieten, wenn mindestens eine der für den Benutzer verfügbaren Zeigereingaben Hover-fähig ist.“

@media (any-pointer: coarse) {
  /* at least one of the pointer inputs
    is coarse, best to make buttons and 
    other "touch targets" bigger (using 
    the query "defensively" to target 
    the least capable input) */
}
@media (any-hover: hover) {
  /* at least one of the inputs is 
     hover-capable, so it's at least 
     possible for users to trigger
     hover-based menus */
}

Aufgrund der Art und Weise, wie any-pointer und any-hover derzeit definiert sind (als „die Vereinigung der Fähigkeiten aller dem Benutzer zur Verfügung stehenden Zeigegeräte“), wird any-pointer: none nur dann wahr, wenn keine Zeigereingaben verfügbar sind, und entscheidender ist, dass any-hover: none nur dann wahr ist, wenn keine der vorhandenen Zeigereingaben Hover-fähig ist. Insbesondere letzteres bedeutet, dass es nicht möglich ist, die Abfrage any-hover: none zu verwenden, um festzustellen, ob nur eine oder mehrere der vorhandenen Zeigereingaben nicht Hover-fähig sind – wir können diese Medien-Feature-Abfrage nur verwenden, um festzustellen, ob alle Eingaben nicht Hover-fähig sind, was genauso gut durch die Prüfung, ob any-hover: hover falsch ausgewertet wird, erreicht werden kann. Dies macht die Abfrage any-hover: none im Wesentlichen überflüssig.

Wir könnten dies umgehen, indem wir daraus schließen, dass wenn any-pointer: coarse wahr ist, es sich wahrscheinlich um einen Touchscreen handelt, und generell diese Eingaben nicht Hover-fähig sind. Konzeptionell treffen wir hier jedoch Annahmen, und sobald es einen groben Zeiger gibt, der auch Hover-fähig ist, bricht diese Logik zusammen. (Und für diejenigen, die bezweifeln, dass wir jemals einen Touchscreen mit Hover sehen werden: Denken Sie daran, dass einige Geräte wie das Samsung Galaxy Note und Microsoft Surface einen Hover-fähigen Stift haben, der auch dann erkannt wird, wenn er den Digitalisierer/Bildschirm nicht berührt, sodass eine Art „Hovering-Touch“-Erkennung in Zukunft nicht ausgeschlossen werden kann.)

Kombination von Abfragen für fundiertere Vermutungen

Die von any-pointer und any-hover bereitgestellten Informationen können natürlich mit pointer und hover sowie der Bestimmung des Browsers, wozu die primäre Eingabe fähig ist, für etwas nuanciertere Einschätzungen kombiniert werden.

@media (pointer: coarse) and (any-pointer: fine) {
  /* the primary input is a touchscreen, but
     there is also a fine input (a mouse or 
     perhaps stylus) present. Make the design
     touch-first, mouse/stylus users can
     still use this just fine (though it may 
     feel a big clunky for them?) */
}
@media (pointer: fine) and (any-pointer: coarse) {
  /* the primary input is a mouse/stylus,
     but there is also a touchscreen 
     present. May be safest to make 
     controls big, just in case users do 
     actually use the touchscreen? */
}
@media (hover: none) and (any-hover: hover) {
  /* the primary input can't hover, but
     the user has at least one other
     input available that would let them
     hover. Do you trust that the primary
     input is in fact what the user is 
     more likely to use, and omit hover-
     based interactions? Or treat hover 
     as something optional — can be 
     used (e.g. to provide shortcuts) to 
     users that do use the mouse, but 
     don't rely on it? */
}

Dynamische Änderungen

Gemäß der Spezifikation sollten Browser Medienabfragen als Reaktion auf Änderungen in der Benutzerumgebung neu auswerten. Das bedeutet, dass sich die Interaktionsmedien-Features pointer, hover, any-pointer und any-hover jederzeit dynamisch ändern können. Zum Beispiel löst das Hinzufügen/Entfernen einer Bluetooth-Maus auf einem Mobil-/Tablet-Gerät eine Änderung von any-pointer / any-hover aus. Ein drastischeres Beispiel wäre ein Surface-Tablet, bei dem das Hinzufügen/Entfernen der „Type Cover“ des Geräts (das eine Tastatur und ein Trackpad enthält) zu Änderungen an der primären Eingabe selbst führt (von pointer: fine / hover: hover bei angebrachtem Cover zu pointer: coarse / hover: none im „Tablet-Modus“ des Surface).

Wenn Sie das Layout/die Funktionalität Ihrer Website basierend auf diesen Medien-Features ändern, seien Sie sich bewusst, dass sich die Website „unter den Füßen des Benutzers“ plötzlich ändern kann, wann immer sich die Eingaben ändern – nicht nur, wenn die Seite/Website zum ersten Mal geladen wird.

Medienabfragen reichen möglicherweise nicht aus – her mit dem Scripting

Der grundlegende Mangel der Interaktionsmedien-Features ist, dass sie uns nicht unbedingt etwas über die gerade jetzt verwendeten Eingabegeräte verraten. Dafür müssen wir tiefer in Lösungen wie What Input? eintauchen, die die spezifisch ausgelösten JavaScript-Ereignisse verfolgen. Aber natürlich können diese Lösungen uns nur Informationen über die Eingabe des Benutzers geben, nachdem er bereits mit der Website interagiert hat – zu diesem Zeitpunkt kann es für drastische Änderungen an Ihrem Layout oder Ihrer Funktionalität zu spät sein.

Beachten Sie, dass selbst diese JavaScript-basierten Ansätze leicht zu falschen Ergebnissen führen können. Das gilt insbesondere für Mobil-/Tablet-Plattformen oder in Situationen, in denen Hilfstechnologien im Spiel sind, wo oft „gefälschte“ Ereignisse erzeugt werden. Wenn wir uns beispielsweise die Reihe der Ereignisse ansehen, die beim Aktivieren eines Steuerelements auf dem Desktop mit einer Tastatur und einem Screenreader ausgelöst werden, können wir sehen, dass gefälschte Mausereignisse ausgelöst werden. Hilfstechnologien tun dies, weil historisch gesehen ein Großteil der Webinhalte für Mausbenutzer und nicht unbedingt für Tastaturbenutzer konzipiert wurde, was eine Simulation dieser Interaktionen für einige Funktionalitäten notwendig macht.

Ebenso ist es beim Aktivieren von „Volle Tastaturunterstützung“ in den iOS-Einstellungen → Bedienungshilfen → Tastatur möglich, dass Benutzer Webinhalte mit einer externen Bluetooth-Tastatur navigieren, genau wie auf dem Desktop. Wenn wir uns jedoch die Ereignissequenz für Mobil-/Tablet-Geräte und gekoppelte Tastatur/Maus ansehen, erzeugt diese Situation Zeigerereignisse, Touch-Ereignisse und Fallback-Mausereignisse – die gleiche Sequenz, die wir für eine Touchscreen-Interaktion erhalten würden.

In all diesen Situationen werden Skripte wie What Input? – verständlicherweise, ohne eigenes Verschulden – den aktuellen Eingabetyp falsch identifizieren.

Falsche Annahmen, die die Erfahrung komplett zunichtemachen können

Nachdem die Komplexität von Multi-Input-Geräten dargelegt wurde, sollte inzwischen klar sein, dass Ansätze, die nur auf bestimmte Arten von Ereignissen hören, wie die Form der gängigen „Touch-Erkennung“, schnell scheitern.

if (window.matchMedia && window.matchMedia("(pointer: coarse)").matches) {
  /* if the pointer is coarse, listen to touch events */
  target.addEventListener("touchstart", ...);
  // ...
} else {
  /* otherwise, listen to mouse and keyboard events */
  target.addEventListener("click", ...);
  // ...
}

Im Falle eines „Touch“-Geräts mit zusätzlichen Eingaben – wie z. B. einem Mobiltelefon oder Tablet mit einer externen Maus – verhindert dieser Code im Wesentlichen, dass der Benutzer etwas anderes als seinen Touchscreen verwenden kann. Und auf Geräten, die hauptsächlich mausgesteuert sind, aber über eine sekundäre Touchscreen-Oberfläche verfügen – wie ein Microsoft Surface –, kann der Benutzer seinen Touchscreen nicht verwenden.

Denken Sie nicht darüber als „Touch oder Maus/Tastatur“, sondern erkennen Sie, dass es oft ein Fall von „Touch und Maus/Tastatur“ ist. Wenn wir aus Performance-Gründen nur Touch-Ereignisse registrieren möchten, wenn tatsächlich ein Touchscreen-Gerät vorhanden ist, können wir versuchen, any-pointer: coarse zu erkennen. Aber wir sollten auch andere reguläre Event-Listener für Maus und Tastatur beibehalten.

/* always, as a matter of course, listen to mouse and keyboard events */
target.addEventListener("click", ...);
 // ...

if (window.matchMedia && window.matchMedia("(any-pointer: coarse)").matches) {
  /* if there's a coarse pointer, *also* listen to touch events */
  target.addEventListener("touchstart", ...);
  // ...
}

Alternativ könnten wir dieses ganze Rätsel über verschiedene Arten von Ereignissen vermeiden, indem wir Pointer Events verwenden, die alle Arten von Zeigereingaben in einem einzigen, einheitlichen Ereignismodell abdecken und recht gut unterstützt werden.

Geben Sie Benutzern eine explizite Wahl

Eine mögliche Lösung, um unsere Unfähigkeit, absolute Bestimmungen darüber zu treffen, welche Art von Eingabe die Benutzer verwenden, geschickt zu umgehen, könnte darin bestehen, die von Medienabfragen und Tools wie What Input? bereitgestellten Informationen nicht sofort zwischen verschiedenen Layouts/Funktionalitäten zu wechseln – oder schlimmer noch, nur auf bestimmte Ereignistypen zu hören und möglicherweise zusätzliche Eingabetypen auszuschließen – sondern sie nur als Signale zu verwenden, wann Benutzern eine explizite Möglichkeit zum Wechseln der Modi angeboten werden soll.

Sehen Sie zum Beispiel, wie Microsoft Office Ihnen erlaubt, zwischen dem „Touch“- und dem „Maus“-Modus zu wechseln. Auf Touch-Geräten wird diese Option standardmäßig in der Symbolleiste der Anwendung angezeigt, während sie auf Nicht-Touch-Geräten zunächst ausgeblendet ist (obwohl sie aktiviert werden kann, unabhängig davon, ob ein Touchscreen vorhanden ist oder nicht).

Eine Website oder Webanwendung könnte den gleichen Ansatz verfolgen und sogar die Standardeinstellung basierend auf der primären Eingabe festlegen – aber den Benutzern trotzdem explizit die Möglichkeit geben, Modi zu wechseln. Und mit einem Ansatz ähnlich wie bei What Input? könnte die Website das erste Auftreten einer Touch-basierten Eingabe erkennen und den Benutzer benachrichtigen/auffordern, ob er zu einem Touch-freundlichen Modus wechseln möchte.

Potenzial für falsche Annahmen – verantwortungsbewusst abfragen

Die Verwendung von Media Queries Level 4 Interaktionsmedien-Features und die Anpassung unserer Websites basierend auf den Merkmalen der verfügbaren primären oder zusätzlichen Zeigereingabe ist eine großartige Idee – aber hüten Sie sich vor falschen Annahmen darüber, was diese Medien-Features tatsächlich aussagen. Wie bei ähnlichen Methoden zur Feature-Erkennung müssen Entwickler wissen, was genau sie erkennen wollen, die Grenzen dieser Erkennung und vor allem darüber nachdenken, warum sie es tun – ähnlich dem Problem das ich in meinem Artikel zur Touch-Erkennung dargelegt habe.

pointer und hover informieren uns über die Fähigkeiten des primären Geräteinputs, wie vom Browser bestimmt. any-pointer und any-hover informieren Sie über die Fähigkeiten aller verbundenen Eingaben und ermöglichen es uns in Kombination mit Informationen über die primäre Zeigereingabe, fundierte Vermutungen über das spezifische Gerät/Szenario eines Benutzers anzustellen. Wir können diese Features nutzen, um unser Layout oder die Art der Interaktion/Funktionalität zu informieren, die wir anbieten möchten; aber unterschätzen Sie nicht die Möglichkeit, dass diese Annahmen falsch sein könnten. Die Medienabfragen selbst sind nicht unbedingt fehlerhaft (obwohl die Tatsache, dass die meisten Browser immer noch Eigenheiten und Fehler aufweisen, zu den potenziellen Problemen beiträgt). Es kommt nur darauf an, wie sie verwendet werden.

Damit möchte ich mit Vorschlägen abschließen, um sich vor den Fallstricken der Eingabedetektion zu „schützen“.