2026 Remote-Mac-Frontend-Abnahme:
Popover API und invoker — Safari vs. Chromium, Vergleichstabelle und progressive Drei-Schritte-Checkliste

Die Popover API ersetzt nicht die Notwendigkeit eines klaren Feature-Checks: Ein Popover kann im DOM existieren, während showPopover() oder deklarative Trigger fehlen oder anders interpretiert werden. Für die Abnahme sollten Sie mindestens prüfen: 'showPopover' in HTMLElement.prototype, das Attribut popover (Werte wie auto oder manual), sowie am auslösenden Element popovertarget und optional popovertargetaction (toggle, show, hide). CSS-seitig kann :popover-open die sichtbare Phase absichern — gemischt mit Utility-Klassen nur, wenn dieselbe Selektor-Logik in beiden Engines getestet ist.

Invoker-Lücke: Wo popovertarget fehlt, muss ein expliziter Klick- oder Tastaturpfad showPopover() und hidePopover() aufrufen. Das gehört in die gleiche Komponente wie die deklarative Variante, damit Linting und Code-Review keine versteckten Zweige übersehen. Anti-Pattern: User-Agent-Sniffing statt Capability-Test — WebKit-Versionen ändern sich schneller als Regex-Pflege.

Zitierfähige Mindestliste vor Merge: (1) Feature-Flags oder Build-Zeit-Konstante für „Popover-Pfad aktiv“. (2) Fallback-Zweig ohne Popover mit gleicher UX-Absicht dokumentiert. (3) Ticket verlinkt Screenshots aus Safari und Chromium mit geleertem Website-Speicher — analog zur ESM-Abnahme, um Cache-Artefakte auszuschließen.

Die Spezifikation ist einheitlich; implementierungsnahe Details zeigen sich bei Top-Layer, Fokus, Tastatur und manchmal bei Anchor Positioning neben dem Popover. Nutzen Sie die Tabelle als Release-Checkliste, nicht als statische Wahrheit — feste Testschritte (Esc, Tab, Klick außerhalb) wiegen schwerer als einmalige Screenshots.

Abnahme-Kennzahl: pro Release zwei Browserfamilien, eine Staging-URL, ein gemeinsames Bedienprotokoll (Esc, Außenklick, Fokus zurück auf den Auslöser). Ergänzend HTTP/3- und Netzwerk-Checks, falls API und Shell aus unterschiedlichen Deploy-Schienen kommen.

Progressive Enhancement bedeutet hier: Zuerst eine funktionierende Baseline ohne Popover (z. B. details/summary, nicht-modal ausklappbare Region), dann die verbesserte Schicht mit API — nie umgekehrt. Polyfills sind kein Ersatz für echtes Safari auf Apple-Hardware, sondern höchstens eine Übergangsbrücke mit dokumentiertem Kosten- und Risikobudget.

Drei-Schritte-Checkliste

1. Baseline sichern: Nutzer können die Aufgabe abschließen, wenn showPopover fehlt — inklusive Tastatur und Screenreader-Grundpfad. Keine toten Buttons durch „nur invoker“.
2. Popover-Pfad einfahren: Dieselbe Staging-URL wie in der Deploy-Checkliste nach Cache-Leerung in Safari und Chromium öffnen; Esc, Außenklick und Fokusrückgabe protokollieren. CI: npx playwright test --project=webkit --project=chromium mit fester baseURL.
3. Polyfill-Grenze: Nur am Eingang (show/hide shim), nicht flächendeckend alle Top-Layer-Semantiken nachbauen. Bundle-Größe und Doppel-Events messen; überschreitet der Polyfill das Budget oder entstehen Race Conditions, Rollforward auf Baseline laut Runbook. Gemeinsame BUILD_ID mit Service-Worker-Abnahme abstimmen, damit Shell und Skripte nicht auseinanderlaufen.

Grenze in einem Satz: Polyfill ja, wenn er klein, idempotent und abschaltbar ist; nein, wenn er die Semantik von Top-Layer und Fokus simuliert, ohne dass Operations die Abweichungen gegenüber der Baseline benennen kann.