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

Dies ist eine aktualisierte und stark erweiterte Version des ursprünglich 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 Arbeitsentwurfs. Sie deckt auch zusätzliche Aspekte im Zusammenhang mit der JavaScript-Erkennung von Touch/Eingabe ab.

Die Interaktionsmedien-Merkmale von Media Queries Level 4 — pointer, hover, any-pointer und any-hover — sollen es Websites ermöglichen, unterschiedliche Stile und Funktionalitäten zu implementieren (entweder CSS-spezifische Interaktivität wie :hover oder JavaScript-Verhalten, wenn sie mit window.matchMedia abgefragt werden), abhängig von den besonderen Merkmalen der Eingabegeräte eines Benutzers.

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

Häufig genannte Anwendungsfälle für Interaktionsmedien-Merkmale sind oft „Steuerelemente größer/kleiner machen, je nachdem, ob der Benutzer ein Touchscreen-Gerät hat oder eine Maus/einen Stift verwendet“ und „nur ein CSS-Dropdown-Menü 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 von Entwicklern, die diese neuen Interaktionsmedien-Merkmale zur Erreichung standardbasierter „Touch-Erkennung“ nutzen, oft nur zum Abhören von Touch-Ereignissen, wenn das Gerät als ein 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 resultieren aus einem Missverständnis dessen, was diese Interaktionsmedien-Abfragen uns mitteilen sollen.

Was ist der *primäre* Eingabetyp?

Eine der Einschränkungen von pointer und hover ist, dass sie per Design nur die Eigenschaften des Eingabegeräts offenlegen, das ein Browser als den *primären* Eingabetyp betrachtet. Was der Browser denkt und was ein Benutzer tatsächlich als seinen primären Eingabetyp verwendet, kann sich unterscheiden – insbesondere jetzt, wo die Grenzen zwischen Geräten und den von ihnen unterstützten Eingabetypen immer verschwommener werden.

Direkt vorab sei darauf hingewiesen, dass *Interaktionsmedien-Merkmale* 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 ist, wie z. B. eine Switch-Steuerung. Theoretisch könnte ein Browser für einen Tastaturbenutzer pointer: none melden und signalisieren, dass die primäre Eingabe des Benutzers überhaupt kein Zeiger ist. In der Praxis bietet jedoch kein Browser eine Möglichkeit für Benutzer, anzugeben, dass sie tatsächlich Tastaturbenutzer sind. Beachten Sie also, dass es unabhängig davon, was die Abfragen der Interaktionsmedien-Merkmale ergeben, ratsam ist sicherzustellen, dass Ihre Website oder App auch für Tastaturbenutzer funktioniert.

Traditionell konnten 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 sicher in iOS landen wird), die er als primären Eingabetyp verwendet.

In diesem Fall, obwohl das Gerät nominell pointer: coarse und hover: none hat, verwenden Benutzer möglicherweise tatsächlich ein feines Zeigergerät, das für Hover-Vorgänge geeignet ist. Ebenso, wenn ein Benutzer einen Stift (wie den Apple Pencil) hat, 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 bietet.

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

Wenn die Website die Hinweise von pointer: coarse für drastischere Änderungen nutzt, wie z. B. das Abhören von Touch-Ereignissen, dann *wird* dies für Benutzer problematisch sein — siehe den Abschnitt über *falsche Annahmen, die das Erlebnis vollständig beeinträchtigen können*.

Betrachten Sie jedoch das Gegenteil: einen „normalen“ Desktop oder Laptop mit Touchscreen, wie z. B. Microsofts Surface. In den meisten Fällen ist die primäre Eingabe das Trackpad/die Maus – mit pointer:fine und hover:hover –, aber der Benutzer verwendet möglicherweise den Touchscreen, der eine grobe Zeigergenauigkeit hat und keine Hover-Funktion besitzt. Wenn Styling und Funktionalität dann speziell auf die Eigenschaften des Trackpads/der Maus zugeschnitten sind, kann der Benutzer es problematisch oder unmöglich finden, 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 eine ähnliche Betrachtung dieses Problems siehe „The Good & Bad of Level 4 Media Queries“ von Stu Cox. Während er sich auf eine noch frühere Iteration der Spezifikation bezieht, die nur pointer und hover enthielt und die Anforderung stellte, dass diese Merkmale das *am wenigsten fähige*, anstatt das *primäre* Eingabegerät melden sollten.

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, einen einzelnen *primären* Eingabetyp korrekt auszuwählen. Hier kommen any-pointer und any-hover ins Spiel.

Testen der Fähigkeiten aller Eingabetypen

Anstatt sich nur auf die *primäre* Zeigereingabe zu konzentrieren, melden any-pointer und any-hover die kombinierten Fähigkeiten *aller* verfügbaren Zeigereingaben.

Um Multi-Input-Szenarien zu unterstützen, bei denen verschiedene (zeigerbasierte) Eingaben unterschiedliche Eigenschaften haben können, kann mehr als einer der Werte für any-pointer (und theoretisch auch any-hover, aber dieser Aspekt ist nutzlos, wie wir später sehen werden) übereinstimmen, wenn unterschiedliche 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 werten diese Medienmerkmale im Allgemeinen wie folgt aus:

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

Zurück zu den ursprünglichen Anwendungsfällen für die Interaktionsmedien-Merkmale: Anstatt unsere Entscheidung, größere oder kleinere Eingaben bereitzustellen oder hover-basierte Funktionalität nur auf den Eigenschaften der *primären* Zeigereingabe zu aktivieren, können wir diese Entscheidung auf den Eigenschaften *jeder* verfügbaren Zeigereingabe basieren. Grob übersetzt: Anstatt zu sagen „alle Steuerelemente vergrößern, wenn die primäre Eingabe pointer: coarse hat“ oder „nur ein CSS-Menü anbieten, wenn die primäre Eingabe hover: hover hat“, können wir Medienabfragen erstellen, die aussagen: „Wenn eine der Zeigereingaben coarse ist, vergrößern Sie die Steuerelemente“ und „Bieten Sie nur ein Hover-basiertes Menü an, 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 als wahr ausgewertet, 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 macht es daher unmöglich, 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 Medienmerkmal-Abfrage nur verwenden, um festzustellen, ob *alle* Eingaben nicht hover-fähig sind, was genauso gut durch die Überprüfung erreicht werden kann, ob any-hover: hover als falsch ausgewertet wird. Dies macht die Abfrage any-hover: none im Wesentlichen überflüssig.

Wir *könnten* dies umgehen, indem wir schließen, dass, wenn any-pointer: coarse wahr ist, es sich wahrscheinlich um einen Touchscreen handelt, und diese Eingaben im Allgemeinen nicht hover-fähig sind, aber konzeptionell treffen wir hier 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 Microsofts Surface einen hover-fähigen Stift haben, der erkannt wird, auch wenn er den Digitizer/Bildschirm nicht berührt, so dass eine Art „Hover-Touch“-Erkennung in Zukunft nicht ausgeschlossen ist.)

Kombinieren von Abfragen für fundiertere Vermutungen

Die von any-pointer und any-hover bereitgestellten Informationen können natürlich mit pointer und hover sowie mit der Bestimmung des Browsers über die Fähigkeiten des *primären* Eingabegeräts kombiniert werden, um etwas differenziertere Bewertungen zu erhalten.

@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 der Benutzerumgebung neu auswerten. Das bedeutet, dass die Interaktionsmedien-Merkmale pointer, hover, any-pointer und any-hover jederzeit dynamisch geändert werden können. So kann beispielsweise das Hinzufügen/Entfernen einer Bluetooth-Maus auf einem Mobil- oder Tablet-Gerät eine Änderung bei any-pointer / any-hover auslösen. 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 der *primären* Eingabe selbst führt (von pointer: fine / hover: hover, wenn das Cover vorhanden ist, zu pointer: coarse / hover: none, wenn sich das Surface im „Tablet-Modus“ befindet).

Wenn Sie das Layout/die Funktionalität Ihrer Website basierend auf diesen Medienmerkmalen ändern, seien Sie sich bewusst, dass sich die Website jederzeit „unter den Füßen des Benutzers“ plötzlich ändern kann — nicht nur beim erstmaligen Laden der Seite/Website.

Medienabfragen reichen möglicherweise nicht aus — her mit dem Skripting

Der grundlegende Mangel der Interaktionsmedien-Merkmale besteht darin, dass sie uns nicht unbedingt etwas über die *aktuell* verwendeten Eingabegeräte verraten. Dafür müssen wir möglicherweise tiefer in Lösungen eintauchen, wie z. B. What Input?, die die spezifisch ausgelösten JavaScript-Ereignisse verfolgen. Aber natürlich können diese Lösungen nur Informationen über die Eingabe des Benutzers liefern, *nachdem* er mit der Website zu interagieren begonnen hat — zu diesem Zeitpunkt kann es zu spät sein, drastische Änderungen an Ihrem Layout oder Ihrer Funktionalität vorzunehmen.

Beachten Sie, dass selbst diese JavaScript-basierten Ansätze leicht zu falschen Ergebnissen führen können. Dies gilt insbesondere auf mobilen/Tablet-Plattformen oder in Situationen, in denen assistive Technologien beteiligt sind, wo „gefälschte“ Ereignisse häufig generiert werden. Wenn wir uns beispielsweise die Serie 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. Assistive Technologien tun dies, weil historisch gesehen ein Großteil des Web-Contents für Mausbenutzer entwickelt wurde, aber nicht unbedingt für Tastaturbenutzer, was eine Simulation dieser Interaktionen für einige Funktionalitäten notwendig macht.

Ebenso ist es, wenn „Full Keyboard Support“ in den iOS-Einstellungen -> Bedienungshilfen -> Tastatur aktiviert ist, möglich, dass Benutzer Webinhalte mit einer externen Bluetooth-Tastatur navigieren, genau wie auf einem Desktop. Wenn wir uns jedoch die Ereignissequenz für Mobil-/Tablet-Geräte und gekoppelte Tastatur/Maus ansehen, erzeugt diese Situation Pointer-Ereignisse, 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 eigene Schuld — den aktuellen Eingabetyp falsch identifizieren.

Falsche Annahmen, die das Erlebnis vollständig beeinträchtigen können

Nachdem wir die Komplexität von Multi-Input-Geräten dargelegt haben, sollte inzwischen klar sein, dass Ansätze, die nur auf bestimmte Ereignistypen reagieren, wie die häufig verwendete Form der „Touch-Erkennung“, schnell versagen.

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 Fall eines „Touch“-Geräts mit zusätzlichen Eingaben — wie z. B. einem Mobil- oder Tablet-Gerät mit einer externen Maus — wird dieser Code im Wesentlichen verhindern, dass der Benutzer etwas anderes als seinen Touchscreen verwenden kann. Und auf Geräten, die primär mausbasiert sind, aber über eine sekundäre Touchscreen-Schnittstelle verfügen — wie z. B. ein Microsoft Surface —, kann der Benutzer seinen Touchscreen nicht verwenden.

Anstatt dies als „Touch *oder* Maus/Tastatur“ zu betrachten, erkennen Sie, dass es sich oft um „Touch *und* Maus/Tastatur“ handelt. Wenn wir nur Touch-Ereignisse registrieren möchten, wenn ein echter Touchscreen vorhanden ist, um die Leistung zu verbessern, können wir versuchen, any-pointer: coarse zu erkennen. Wir sollten jedoch auch andere normale Ereignis-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 diesen gesamten Konflikt über verschiedene Ereignistypen vermeiden, indem wir Pointer-Ereignisse verwenden, die alle Arten von Zeigereingaben in einem einzigen, einheitlichen Ereignismodell abdecken und ziemlich gut unterstützt werden.

Benutzern eine explizite Wahl geben

Eine mögliche Lösung, um unsere Unfähigkeit, absolute Bestimmungen darüber zu treffen, welchen Eingabetyp die Benutzer gerade verwenden, elegant zu umgehen, besteht darin, die von den Medienabfragen und Tools wie What Input? bereitgestellten Informationen nicht sofort zwischen verschiedenen Layouts/Funktionalitäten zu wechseln — oder schlimmer noch, nur bestimmte Ereignistypen zu hören und möglicherweise zusätzliche Eingabetypen auszuschließen —, sondern sie nur als Signale zu verwenden, um den Benutzern eine explizite Möglichkeit zum Wechseln der Modi zu bieten.

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

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

Potenzial für falsche Annahmen — verantwortungsvoll abfragen

Die Verwendung von Media Queries Level 4 Interaction Media Features und die Anpassung unserer Websites basierend auf den Eigenschaften 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 Medienmerkmale tatsächlich aussagen. Wie bei ähnlichen Methoden zur Feature-Erkennung müssen Entwickler sich bewusst sein, was genau sie erkennen wollen, welche Einschränkungen diese Erkennung hat und vor allem, *warum* sie es tun — ähnlich dem Problem, das ich in meinem Artikel zur Erkennung von Touch beschrieben habe.

pointer und hover informieren uns über die Fähigkeiten des Eingabegeräts, das der Browser als primär 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 spezielle Gerät/Szenario eines Benutzers anzustellen. Wir können diese Merkmale nutzen, um unser Layout oder die Art der Interaktion/Funktionalität, die wir anbieten möchten, zu informieren; 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 zu haben scheinen, zu den potenziellen Problemen beiträgt). Es hängt nur davon ab, wie sie verwendet werden.

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