Zusammenfassung

  • Der erste öffentliche W3C-Entwurf vom Juni 2023 beschrieb, wie ein positioniertes Element seine Lage und Größe an einem Ankerelement anderswo auf der Seite ausrichten kann; für überlaufende Positionen sah er Alternativen vor.
  • Die Entwürfe von 2024 entwickelten die Wahl des Standardankers und die position-try-Regeln. Die Webseite ordnet geeignete Plätze, der Browser misst, welcher in den verfügbaren Raum passt.

Ein Formular verlangt eine schwer verständliche Angabe. Neben dem Feld steht ein kleines Hilfezeichen. Der Leser klickt und erwartet eine knappe Erklärung genau dort. Auf einem breiten Monitor ist rechts vom Zeichen genügend Platz. Auf einem Telefon drängt derselbe Platzierungswunsch den halben Satz hinter den Bildschirmrand. Die Blase hat ihren Knopf gefunden, aber ihren Leser verloren. Im Werkzeugkasten des Entwicklers klappern erneut top, left und Rechnungen, die beim letzten Bildschirmformat noch gestimmt haben.

Der erste öffentliche W3C-Entwurf zu CSS Anchor Positioning vom 29. Juni 2023 gab der Lagebeziehung eine eigene Sprache. Ein positioniertes Element kann sich in Größe und Lage an einem oder mehreren Ankerelementen anderswo auf der Seite orientieren. anchor-name benennt den Bezugspunkt; anchor() und anchor-size() nutzen dessen Position oder Maße. Die Blase bleibt ein eigenes Kästchen, kennt aber die Schaltfläche, zu der sie gehört. Wird eine Zeile über dem Feld länger und verschiebt den Knopf, verschiebt sich der Bezug gleich mit.

Die Seite bestimmt, zu welchem Feld der Hinweis gehört und was er sagen soll. Für die Platzierung kennt der Browser bereits die Geometrie beider Kästen. Der Entwurf von Juni 2023 gab ihm mit position-fallback und @position-fallback weitere Anweisungen für den Rand: Passt der bevorzugte Platz nicht in den umschließenden Bereich, kommen vorher festgelegte Alternativen an die Reihe. Rechts wird eng? Dann ist links eine bewusste zweite Wahl, kein Unfall der Pixelrechnung.

An der Schreibweise wurde gearbeitet. Der Text vom 14. März und der vom 26. März 2024 führten position-anchor für den ausdrücklich benannten Standardanker und position-try-options für Ersatzplätze. Im Oktoberentwurf hieß diese Liste position-try-fallbacks. Die drei Bezeichnungen stammen aus unterschiedlichen Fassungen. Entscheidend ist, dass ein Element seinen Bezugspunkt benennen kann, bevor über freie Plätze gestritten wird.

Der Oktobertext zeigt dafür einen konkreten Fall. Eine Hilfe sitzt mit position-area: block-start mittig über ihrem Knopf. position-try: flip-block schickt sie unter den Knopf, wenn der obere Rand keinen Raum lässt. Zwei kurze Regeln beschreiben das Verhalten, das früher oft eine Sammlung von top- und left-Werten samt Bildschirmbreitenprüfungen brauchte. Auf dem Telefon gewinnt der Leser den abgeschnittenen Halbsatz zurück.

Für längere Kästen reicht ein bloßes Oben-oder-unten-Spiel nicht immer. position-try-order kann die Kandidaten in der geschriebenen Reihenfolge prüfen oder den Platz mit der größten Breite beziehungsweise Höhe bevorzugen. Der Entwurf verwendet dafür eine aufklappende Liste an einem Knopf: Sie soll auf der Seite landen, auf der möglichst viele Einträge sichtbar bleiben. Wer nur die Spitze einer Auswahl sieht, kann schlecht auswählen. Der Rand bestimmt damit nicht allein die Position, sondern auch die Nutzbarkeit des Inhalts.

Der Text widmet dem Scrollen einen eigenen Abschnitt. Das ist kein akademischer Umweg: Der Knopf kann in einem scrollbaren Bereich liegen, während die Hilfe außerhalb dieses Bereichs positioniert ist. Der Entwurf beschreibt, wie der Versatz beim Scrollen berücksichtigt wird, und begrenzt Fälle, in denen die Größe einer solchen Hilfe von einem anderswo scrollenden Anker abhängen darf. So kann das Verschieben auf einer eigenen Verarbeitungsspur bleiben, statt bei jedem Bild die ganze Seite neu zu setzen.

Auch eine optisch saubere Verbindung ist noch keine verständliche Verbindung für alle. Der Abschnitt zur Zugänglichkeit erklärt, dass Anchor Positioning allein keine semantische Beziehung zwischen Knopf und Hinweis herstellt. Die Popover API verbindet ihren auslösenden Knopf mit dem Popover und kann ihm diesen Knopf zugleich als impliziten Anker geben. Andere Fälle brauchen etwa aria-describedby oder aria-details. Eine Hilfe, die sichtbar am richtigen Feld klebt, aber vom Screenreader ohne Zusammenhang vorgelesen wird, hat den halben Auftrag erledigt.

Die W3C-Veröffentlichungsgeschichte führt vom ersten Text 2023 zu diesen feineren Entscheidungen 2024. Der knappe Erfolg der Geschichte liegt am Bildschirmrand: Der Hinweis findet einen lesbaren Platz, während sein Knopf genau dort bleiben darf, wo das Formular ihn braucht.