Lesetipp: Stay alert!

[1unitedpower]

Die Entscheidung wurde vom WHATWG getroffen.

Die Initiative kommt von carlosjoan91, einem Google-Mitarbeiter, und im Issue gibt es diverse Proteste von anderen. Die Folge: Das Issue wurde als "off topic" und "too heated" gesperrt.

Also vorweg: Der Standard hat auch vor der Änderung schon hergegeben, dass Chrome Dialoge von cross-origin iframes blockiert. Das erlaubt Schritt 4 aus diesem Algorithmus. Dieser Schritt erlaubt das Blockieren von Dialogen aus beliebigen Gründen. Aber offenkundig wollte das Chrome-Team auch, dass andere Browser-Hersteller ihrer geplanten Implementierung folgen, also haben sie das WHATWG angerufen, um einen Konsens herbei zu führen. Das Firefox-Team hat sich dem angeschlossen.

Von der Eröffnung des Proposals bis zur Aufnahme in den Standard hat es im GitHub-Issue keine Kritik gegeben. Die Kritik kam erst auf, nachdem eine Beta-Version von Chrome mit der Implementierung erschienen ist. Und die Kritik basiert scheinbar auf der falschen Annahme, dass diese Spec-Änderung die Implementierung in Chrome erst möglich gemacht hat. Das WHATWG ist daraufhin moderativ eingeschritten und hat versucht die Kritiker:innen an die richtige Adresse für die Kritik zu verweisen (das Chrome-Team) und gebeten, den Thread nur nur für Fragen an die Spec zu nutzen. Der Hinweis wurde ignoriert, und das WHATWG hat den Thread geschlossen.

Ich will hier auch niemanden in Schutz nehmen, man kann gerne über diese Vorgehensweise und den generellen Standardisierungsprozess streiten.

Ich halte es für grundsätzlich okay, dass das Sandbox-Attribut einer Seite modale Dialoge verbietet und man sie mit allow-modals wieder freigeben kann.

Das halte ich für keine adequate Lösung. Es führt dazu, dass Web-Entwickler:innen das Attribut beim ersten Problem einfach setzen, um das Problem beiseite zu schaffen. Dadurch ensteht für die Anwender:innen aber wieder ein Sicherheitsrisiko.

Der Grund ist mMn bekloppt: Der Anwender erkennt nicht, ob der modale Dialog von der iframe-Seite oder von der Host-Seite kommt (was schlecht ist), deswegen muss man dem Dialog einen Hinweis hinzufügen, woher der Dialog kommt (was gut ist), aber dann sind manche Anwender über den Hinweis verwirrt.

Also, wie schon gesagt, ich kann den Grund gut nachvollziehen. Das Web sollte für alle Menschen nutzbar sein, und nicht für technik-affine Geeks. Einen Hinweis oder eine URL an einen Dialog zu schreiben ist keine adequate Lösung, die jede Benutzer:in gleich durchschaut. Dafür müsste ja zunächst mal ein Problem-Beweusstsein bei der Anwender:in vorliegen. Und dann müsste man auch noch wissen, wie diese Hinweise zu lesen sind.

Außerdem traten zwei der drei im Proposal verlinkten Sicherheitslücken bei Dialogen auf, die bereits mit einem solchen Hinweis versehen waren.

und das tolle "alles auf einer Seite" Design mit viel Freiraum, parallax scroll und megabyteschweren, aussagefreien Hintergrundbildern genießen kann. ARGH!

Jetzt entfernst du dich etwas zu weit vom Thema.