Frage zum Wiki-Artikel „dialog“

[Rolf B]

Hallo alle,

ich überarbeite diesen Beitrag gerade. Etliches von dem, was 1UP damals da rein tippte, ist heute nicht mehr in der Spec. Dafür fehlen Forms mit method="dialog".

Ich finde dabei einen länglichen Abschnitt mit 8 Jahre alten Wurzeln über das Öffnen von Dialogen mit der :target-Pseudoklasse statt mit CSS.

Aus meiner Sicht ist das ein Antipattern und gehört da 'raus, denn

• Links sind Links und keine Buttons, die auf der aktuellen Seite Dinge auslösen sollten
• Man kann auf diese Weise keine modalen Dialoge öffnen - der Backdrop erscheint demzufolge nicht
• Wenn ein solcher Dialog offen ist, braucht er einen weiteren Link, um ihn wieder zu schließen. Denn da er ja per CSS zwangsweise sichtbar gemacht wird, helfen die im Browser eingebauten Close-Mechanismen (die das open-Attribut entfernen möchten) nicht.
• Die :target-Pseodoklasse zwingt den Dialog zwar aus der Versenkung, setzt aber das open-Attribut nicht und setzt auch keinen Fokus in den Dialog. Das ist sicherlich nicht das, womit Assistenztechniken rechnen.

Ich könnte mir als Rechtfertigung für diesen Abschnitt vorstellen, dass dieser CSS Trick aus Zeiten stammt wo das dialog-Element noch gar nicht von den Browsern unterstützt wurde und es auch noch keinen ordentlichen Polyfill gab. Beides ist heute nicht mehr der Fall.

Gibt es Widerspruch gegen das Entfernen dieses Abschnitts?

Rolf

[Camping_RIDER]

Aloha ;)

Gibt es Widerspruch gegen das Entfernen dieses Abschnitts?

Nein, ich sehe das sehr ähnlich wie du. Überholte Dinge entfernen zu können ist ja gerade einer der Vorteile eines Wiki.

Grüße,

RIDER

[Henry]

Hallo Rolf,

Ich könnte mir als Rechtfertigung für diesen Abschnitt vorstellen, dass dieser CSS Trick aus Zeiten stammt wo das dialog-Element noch gar nicht von den Browsern unterstützt wurde und es auch noch keinen ordentlichen Polyfill gab. Beides ist heute nicht mehr der Fall.

FF unterstützt das immer noch nicht.

Gibt es Widerspruch gegen das Entfernen dieses Abschnitts?

Nein, so oder so könnte der verständlicher sein.

Gruss
Henry

[JürgenB]

Hallo,

FF unterstützt das immer noch nicht.

wer hätte gedacht, das ein „Microsoft“-Browser mal mehr kann als der FF und auch noch einen höheren Marktanteil hat 😀. FF, quo vadis?

Gibt es Widerspruch gegen das Entfernen dieses Abschnitts?

nein. Solange Browser, die die moderne Technik bzw. den Polyfill nicht unterstützen, nicht ausgesperrt werden, ist das OK.

Gruß
Jürgen

[Der Martin]

Hallo Jürgen,

FF unterstützt das immer noch nicht.

wer hätte gedacht, das ein „Microsoft“-Browser mal mehr kann als der FF und auch noch einen höheren Marktanteil hat 😀. FF, quo vadis?

naja, der derzeitige Edge ist ja ebensowenig ein Microsoft-Browser wie der aktuelle Opera wirklich ein Opera ist. Es sind kostümierte Google-Browser.

Warum Chromium-basierte Browser in letzter Zeit so auf dem Vormarsch sind und FF dabei hinter sich gelassen haben, ist mir allerdings auch ein Rätsel. Andererseits: Der Internet Explorer hatte auch mal die absolute Mehrheit.
Gut finden muss man das trotzdem nicht.

Live long and pros healthy,
 Martin

[Rolf B]

Hallo Martin,

sollen wir den Selfari schreiben und damit die Welt erobern?

😨🙊🤣

Rolf

[Rolf B]

Hallo JürgenB,

wer hätte gedacht, das ein „Microsoft“-Browser mal mehr kann als der FF und auch noch einen höheren Marktanteil hat 😀. FF, quo vadis?

Eher „quo claudicas^[1]?“...

Solange Browser, die die moderne Technik bzw. den Polyfill nicht unterstützen, nicht ausgesperrt werden, ist das OK.

Die Autoren schreiben:

This polyfill works on modern versions of all major browsers. It also supports IE9 and above. It can work when used inside Shadow DOM, but it's not recommended.

Aber die Frage ist natürlich: wie geht man damit um, wenn der Polyfill nicht wirkt. Eine Seite, die Javascript-getriebene Buttons verwendet, um Dialoge zu öffnen, wäre damit grundsätzlich nicht realisierbar oder müsste ihre Buttons in Formulare stecken, um im Zweifelsfall per Server zu agieren. ASP.NET Webforms gehen so vor. Müsste man so eine Technik im Wiki vorstellen?

Rolf

---

1. claudicare: humpeln, hinken ↩︎

[JürgenB]

Hallo Rolf,

Aber die Frage ist natürlich: wie geht man damit um, wenn der Polyfill nicht wirkt. Eine Seite, die Javascript-getriebene Buttons verwendet, um Dialoge zu öffnen, wäre damit grundsätzlich nicht realisierbar oder müsste ihre Buttons in Formulare stecken, um im Zweifelsfall per Server zu agieren. ASP.NET Webforms gehen so vor. Müsste man so eine Technik im Wiki vorstellen?

nein, allenfalls erwähnen. Ich bin der Meinung, wer Javascript abschaltet, muss mit den Konsequenzen leben.

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

oha. Eine Seite, die das Einschalten von JS voraussetzt, um essenzielle Funktionen bereitstellen zu können? Sowas gibt's reichlich im Wilden Wirren Web, aber ob das den Regeln für gutes Webdesign entspricht?

Rolf

[JürgenB]

Hallo Rolf,

oha. Eine Seite, die das Einschalten von JS voraussetzt, um essenzielle Funktionen bereitstellen zu können? Sowas gibt's reichlich im Wilden Wirren Web, aber ob das den Regeln für gutes Webdesign entspricht?

die Frage ist, was ist essentiell.

• Teile, die mit Javascript ein- und ausgeblendet werden können, sind ohne JS immer offen.
• Dialoge, die am Ende eine Serveraktion auslesen, haben schon eine Serverunterstützung und daher ist es ohne zu großen Aufwand möglich, die (komfortablen) JS-Dialoge durch so etwas wie ein Affenformular zu ersetzen.
• Aber Seiten, die direkt auf eine Useraktion reagieren, z.B. Drehen einer 3D-Grafik mit der Maus, werden ohne Javascript eben nicht funktionieren bzw. nur statisch sein können. Ich weise dann die Besucher darauf hin, dass ohne Javascript und ohne modernen Browser nichts geht. Evtl. biete ich dann einen statischen Ersatz an. Aber da ich mit meinen Seiten kein Geld verdiene, kann ich es mir auch erlauben, auf Besucher ohne Javascript zu verzichten.

Gruß
Jürgen

[Rolf B]

Hallo Jürgen,

Teile, die mit Javascript ein- und ausgeblendet werden können, sind ohne JS immer offen.

Ein dialog-Element ohne open Attribut ist ohne JS immer zu.

Sollte man also allen Dialog-Elementen im HTML das open-Attribut geben und dieses per JS beim Seitenstart entfernen? Dann sind ohne JS alle Dialoge offen.

Das setzt aber eine sinnvolle Platzierung der Dialoge voraus, und ist bei modalen Dialogen sinnfrei. Abgesehen davon weist die Spec ausdrücklich darauf hin, das open-Attribut nicht per removeAttribute zu entfernen, sondern close() zu verwenden, d.h. man müsste per JS zuerst mal alle Dialoge closen und DANN die Event-Handler für Close registrieren.

Brrr. Es scheint, als wäre das Dialog-Konzept nicht für Seiten gedacht, die auch ohne JS funktionieren sollen. Dafür bräuchte es einen Trigger-Mechanismus auf HTML-Ebene, der ohne JS funktioniert.

Rolf

[JürgenB]

Hallo Rolf,

Teile, die mit Javascript ein- und ausgeblendet werden können, sind ohne JS immer offen.

Ein dialog-Element ohne open Attribut ist ohne JS immer zu.

Sollte man also allen Dialog-Elementen im HTML das open-Attribut geben und dieses per JS beim Seitenstart entfernen? Dann sind ohne JS alle Dialoge offen.

das wäre eine Option.

Das setzt aber eine sinnvolle Platzierung der Dialoge voraus, und ist bei modalen Dialogen sinnfrei. Abgesehen davon weist die Spec ausdrücklich darauf hin, das open-Attribut nicht per removeAttribute zu entfernen, sondern close() zu verwenden, d.h. man müsste per JS zuerst mal alle Dialoge closen und DANN die Event-Handler für Close registrieren.

Brrr. Es scheint, als wäre das Dialog-Konzept nicht für Seiten gedacht, die auch ohne JS funktionieren sollen. Dafür bräuchte es einen Trigger-Mechanismus auf HTML-Ebene, der ohne JS funktioniert.

z.B. <noscript>

Wer Javascript abschaltet, hat dafür seine Gründe und muss dann abwägen, ob die sich daraus ergebenden Vorteile überwiegen. Webseiten können eben mehr sein, als statische Visitenkarten, und da braucht man oft auch Javascript.

Viele Javascript-Features sind nur Komfort, z.B. Schließen des Menüs bei der ESC-Taste, etc.. Wenn die fehlen, was soll's. Wenn alle Dialoge oder in der Navigation alle Submenüs offen sind, was soll's. Wenn natürlich dann absolut positionierte Elemente andere Teile überdecken, geht das nicht mehr. Letztendlich muss man problemabhängig entscheiden, ob man eine javascriptfreie Alternative anbietet, oder ob man den Besucher nur auf sein abgeschaltetes Javascript hinweist.

Und auch hier stelle ich noch mal die Frage: Wie schalte ich beim Smartphone Javascript ab? Und jetzt ohne Nachdenken und Suchen: Wie schalte ich beim Desktopbrowser Javascript ab?

Ich vermute mal, es gibt mehr Seitenbesucher mit einer Behinderung Einschränkung, als Seitenbesucher ohne Javascript. Man sollte sich lieber erst mal um die kümmern.

Gruß
Jürgen

[Rolf B]

Hallo Jürgen,

Und auch hier stelle ich noch mal die Frage: Wie schalte ich beim Smartphone Javascript ab? Und jetzt ohne Nachdenken und Suchen: Wie schalte ich beim Desktopbrowser Javascript ab?

Ich öffne die Browsereinstellungen und tippe "JavaScript" ins Suchfeld...

Ich vermute mal, es gibt mehr Seitenbesucher mit einer Behinderung Einschränkung, als Seitenbesucher ohne Javascript. Man sollte sich lieber erst mal um die kümmern.

Sorry, das ist ein rhetorisches Ablenkungsmanöver. Dein Schlusssatz erinnert an die Leute, die von eigenen Mängeln durch den Hinweis auf die viel größeren Mängel an anderer Stelle ablenken. Nein, ich will Dir keine Mängel andichten. Aber ich mag auch nicht sagen: Meine Seite funktioniert ohne JS überhaupt nicht, aber das ist mir egal, weil sie mit JS so super zugänglich ist.

Wenn Du meinst, dass unser Wiki eher Arbeit in Zugänglichkeit investieren sollte statt in "wie kommt man ohne JS aus", ja ok. Aber an Knackpunkten wie dialog, die ohne JS unbrauchbar sind, muss man an die Frage "was tun ohne JS" wohl heran.

Rolf

[JürgenB]

Hallo Rolf,

Und auch hier stelle ich noch mal die Frage: Wie schalte ich beim Smartphone Javascript ab? Und jetzt ohne Nachdenken und Suchen: Wie schalte ich beim Desktopbrowser Javascript ab?

Ich öffne die Browsereinstellungen und tippe "JavaScript" ins Suchfeld...

gerade im FF versucht, da kommt nichts. Ich kenne hier nur den Weg über about:config. Aber sowohl „Einstellungen“ als auch about:config sind keine Gegenden, wo man den Otto-Normal-User findet.

Wenn Du meinst, dass unser Wiki eher Arbeit in Zugänglichkeit investieren sollte statt in "wie kommt man ohne JS aus", ja ok.

genau das meine ich.

Aber an Knackpunkten wie dialog, die ohne JS unbrauchbar sind, muss man an die Frage "was tun ohne JS" wohl heran.

Wenn ich für das Ausfüllen eines Formulars oder für die Cookie-Abfrage Javascript zwingend voraussetze, ist das natürlich falsch. Die Adresse im Impressum muss ich auch ohne JS sehen. Aber die Javascript-Alternative darf mMn ruhig „dahin gerotzt“ sein. Da muss nicht viel Mühe für ein tolles Design aufgebracht werden.

Für mich können Webseiten kleine Programme sein. Webseiten können Dateien lesen, Daten bearbeiten und das Ergebnis abspeichern. Webseiten können Daten interaktiv visualisieren. Nimm z.B. das Corona-Dashboard, ich kann mir nicht vorstellen, wie so etwas ohne JS gehen soll.

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

Corona-Dashboard, ich kann mir nicht vorstellen, wie so etwas ohne JS gehen soll.

Challenge accepted 🤣

Mit Scrollpanels und ismap-Attribut auf den Bildern kann man bestimmt eine Menge erreichen. Performance war keine Anforderung, oder?

Rolf

[Der Martin]

Hallo Rolf,

Corona-Dashboard, ich kann mir nicht vorstellen, wie so etwas ohne JS gehen soll.

Challenge accepted 🤣

Chapeau!

Performance war keine Anforderung, oder?

Ich denke, nein. Das Corona-Dashboard der JHU ist ja in seiner derzeitigen Form schon ein Fiasko, was die Performance angeht. Das ist sicher dem Bestreben geschuldet, sämtliche Informationen auf eine Seite zu quetschen (ich hätte mehrere daraus gemacht), und dann einfach auch der schieren Informationsmenge.

Bei mir braucht das jedenfalls mit dem Firmen-Notebook und im "schnellen" Firmennetzwerk zwischen einer halben und einer Minute, bis es fertig geladen ist. Und in der Zeit dreht der Lüfter hörbar hoch, was auf eine hohe CPU-Last schließen lässt.
Zuhause an einem DSL16000 dauert's noch länger.

Live long and pros healthy,
 Martin

[Camping_RIDER]

Aloha ;)

Ohne mich groß einmischen zu wollen: Ich muss Jürgen da nur zustimmen. Ich bin auch einer derjenigen, der noch bis vor kurzer Zeit versucht hat, auf Biegen und Brechen zu versuchen, hübsche, funktionale JS-frei funktionierende Webseitenelemente zu entwickeln - aber selbst ich musste kapitulieren.

Es ist einfach so, dass das Ausschalten von JavaScript heute nicht mehr zu den Dingen gehört, die Otto Normalverbraucher noch tut. Das tun wenn-dann die Experten, denen es nachher auch relativ wurscht ist, wie das Ding aussieht, Hauptsache Kern-Bedienbarkeit ist nach Möglichkeit gegeben.

Das zeigt auch das Browserverhalten - wie ihr schon festgestellt habt, wurde die entsprechende Einstellung aus den Einstellungen-GUIs aller namhafter Browser entfernt... Das kann man, denke ich, durchaus argumentativ heranziehen.

Das, was Jürgen vorschlägt, ist astreines progressive enhancement. Ohne JavaScript gibts halt Basisfunktionalität (grundsätzliche Bedienbarkeit), die so weit geht, wie es ohne JavaScript schmerzlos möglich ist, und schön oder komfortabel wirds dann mit JavaScript.

Natürlich sollte man sich trotzdem immer die Frage stellen, ob man jetzt wirklich JavaScript braucht. Das beste Script ist kein Script, wenn man stattdessen eine gute, geradlinige andere Lösung findet.

Grüße,

RIDER

[Rolf B]

Hallo Janosch,

ich möchte ja gar nicht generalisieren. Ich komme ja vom dialog-Element.

Das beste Script ist kein Script, wenn man stattdessen eine gute, geradlinige andere Lösung findet.

Die bei <dialog> nicht existiert. Die im Wiki genannte CSS Idee (Dialog via :target anzeigen) macht mMn mehr Probleme als sie löst.

Und das Ergebnis der Debatte ist: Wenn ein Dialog Dinge anbietet, die für die Funktion der Seite essenziell sind, kann ich <dialog> nicht verwenden. Weil JS immer mal unterdrückt sein kann oder - Gunnars Standardbeispiel - die .js Datei im Funkloch verschwunden ist.

Bei einer Seite mit stark modularem JS kann das natürlich noch zu den verrücktesten Mischbedingungen führen, weshalb man die Scripte zumindest bündeln sollte.

Ich fühle mich hiermit also orientiert - danke 😀

Rolf