Zusammenfassung

  • Der erste öffentliche W3C-Entwurf von Dezember 2012 schlug eine geräteunabhängige Ereignisfamilie für Maus, Stift und Berührung vor und berücksichtigte bestehende Maus-Seiten.
  • Die W3C-Empfehlung von Februar 2015 regelte Pointer Events, pointerType, touch-action für Touch-Gesten und Pointer Capture für Bewegungen außerhalb eines Elements.

Am Eingang des Mausclubs steht ein Pförtner mit nur einem Feld im Anmeldebuch. Ein Finger erscheint; für ältere Seiten kann der Browser ihm einen Maus-Event als Verkleidung mitgeben. Das hält den Laden offen, macht aber die Herkunft des Besuchers unklar. Mit einem Stift an der Tür reicht die Verkleidungskiste irgendwann nicht mehr.

Der erste öffentliche Pointer-Events-Arbeitsentwurf des W3C vom 11. Dezember 2012 erklärte die Rechnung. Websites hatten ihre eigene Interaktionslogik für Mouse Events gebaut. Separate Ereignisfamilien für Berührung und Stift verlangten ähnliche Logik noch einmal. Kompatibilitätsereignisse konnten zudem so tun, als sei ein Finger eine Maus. Ein abstrakter Pointer sollte jeden Kontakt beschreiben, der eine Bildschirmposition bezeichnet.

Gemeinsam heißt hier nicht gleichförmig. PointerEvent kann pointerType, Druck, Kontaktfläche und Neigung tragen. Ein Nachrichtenknopf muss womöglich nur auf das Drücken reagieren. Eine Zeichenfläche möchte wissen, wie fest und schräg der Stift aufliegt. Die Website kann zunächst das gewöhnliche Verhalten teilen und für besondere Aufgaben die passenden Eigenschaften hinzunehmen.

Die W3C-Empfehlung vom 24. Februar 2015 beschreibt unter anderem pointerdown, pointermove, pointerup und pointercancel sowie Ereignisse beim Betreten und Verlassen einer Fläche. Die Namen ähneln den alten Mausereignissen. Eine Pointer-ID hält die Bewegungen auseinander, wenn mehrere Finger beteiligt sind. Der Club vergrößerte seine Tür, ohne das ganze Gebäude umzubenennen.

Alte Inhalte behielten ihren Zugang. Die Empfehlung beschreibt die Erzeugung kompatibler Mouse Events aus anderen Pointer-Arten. Ein älterer Knopf kann dadurch auch auf Berührung reagieren. Die Hilfe hat jedoch einen Preis in Klarheit: Ein Mouse Event kann die Spur eines Fingers sein. Neues Verhalten liest pointerType, wenn die Art des Werkzeugs eine Rolle spielt.

Beim Wischen treffen zwei Zuständigkeiten aufeinander. Will der Mensch eine Karte ziehen oder das Dokument scrollen? Müsste der Browser für jede Bewegung abwarten, ob ein Skript sie nachträglich untersagt, würde Scrollen schwerfällig. Die CSS-Eigenschaft touch-action erklärt vorab, welche üblichen Touch-Aktionen in einem Bereich erlaubt sind. Der Browser kann seine Scrollarbeit verrichten, statt bei jedem Zentimeter das Skript um Erlaubnis zu bitten.

Pointer Capture löst ein anderes Alltagsproblem. Jemand zieht einen kleinen Schieber und rutscht mit dem Finger aus dessen Rechteck. Das Element kann die Ereignisse dieses Pointers weiterhin erhalten, obwohl die Position nun außerhalb liegt. Der Text von 2015 beschreibt das Setzen und Lösen der Capture sowie gotpointercapture und lostpointercapture. Ein Ziehen soll nicht abbrechen, bloß weil die Hand eine etwas weitere Kurve nimmt.

Die Geräte behalten ihre Eigenschaften. Der Finger berührt eine Fläche, der Stift kann Druck und Neigung melden, die Maus besitzt Tasten. Eine gemeinsame Ereignisfamilie spart doppelte Wege im Code. Die besonderen Felder stehen bereit, wo sie einem Zeichenprogramm oder einer präzisen Bedienung helfen. Niemand muss den Stift zum mausförmigen Gegenstand schnitzen.

Die W3C-Publikationsgeschichte von Pointer Events 1 verzeichnet den ersten öffentlichen Entwurf 2012 und die Empfehlung 2015. Die Dokumente antworteten auf ein ganz handfestes Problem: Das Web hatte für die Maus gebaut, während Menschen zunehmend direkt auf Bildschirme fassten und mit Stiften zeichneten.

Für Leser zählt am Ende kein Eventname. Ein Knopf reagiert, die Seite scrollt flüssig und ein Ziehen bleibt auch jenseits einer unsichtbaren Kante erhalten. Die Maus darf Stammgast bleiben. Sie muss nur den Tisch teilen.