Hallo JürgenB, ich würde auf einen fertigen Polyfill aus reputabler Quelle verweisen, wie [den hier](https://github.com/GoogleChrome/dialog-polyfill). Der verwendet übrigens eine register-Methode, so wie ich. Und ich hab da nicht abgeguckt 😂 ~~~js if (!window.HTMLDialogElement) { // dialog-polyfill.css hinzufügen // dialog-polyfill.js hinzufügen (manuell, AMD) // ODER dialog-polyfill.esm.js hinzufügen (ES6-import) } ~~~ Und dann kann man sich - unbehindert durch Fragen zum Polyfill an sich - um Dinge kümmern wie Focus-restore oder Button-Steuerung. Beim Google-Polyfill schreiben sie zu dem Thema: > **Focus** > The WAI-ARIA doc suggests returning focus to the previously focused element after a modal dialog is closed. However, this is not part of the dialog spec itself. See [this snippet](https://gist.github.com/samthor/babe9fad4a65625b301ba482dad284d1) to add this, even to the native dialog. Nicht jedes Rad ist so eckig, dass man es neu erfinden muss 😉 Im Firefox klappt die Fokussierung eines Dialog-Buttons übrigens prima, der Fokus wird vom Firefox angezeigt. In Chrome wird der Button durchaus fokussiert, der richtige Button reagiert auf ENTER, aber er zeigt es, solange keine :focus CSS Regel existiert, einfach nicht an! Man muss einmal Tab drücken, dann erst erscheint der Fokus-Rand am Button. Da hilft auch kein setTimeout, sehr merkwürdig. Das ätzende ist, dass man einen fokussierten Button per CSS nicht so stylen kann wie Chrome das ab Werk tut. Buttons in einem Dialog kann man übrigens viel einfacher handeln als mit einer click-Handler Registrierung: Man setzt ein <form method="dialog"> in den Dialog. Klickt man einen Button, wird sein value zum returnValue des Dialogs. Brrr - wieso sagt einem das keiner? Nachdem ich das entdeckt habe, habe ich mein eigenes Buttonhandling gleich wieder rausgeschmissen. Guck mal hierhin: <http://dialog-test.borchmann.one/dialog-test.html>. Einfach nur mal als alternative Möglichkeit. Guck erstmal nur in die dialog-test.html, das ist das, was ein Anwender programmieren und designen würde. Das Öffnen der Dialoge und das Handhaben des Rückgabewertes ist dort implementiert - stupide, für eine Testshell. Spezialitäten meines DialogHandlers: * show/showModal geben ein Promise zurück. Man muss keinen close-Eventhandler registrieren, man hängt sich einfach mit .then an show()/showModal() an. * wer ganz modern ist, baut eine async function und verwendet await, statt mit .then einen Callback zu registrieren. Boah ey 😂. Ist aber nur Syntaxzucker für Promises und .then(). * ich unterstütze ein paar data-Attribute am Dialog: * data-default: Der value des Buttons, der zu Beginn fokussiert sein soll. * data-cancel: Der returnValue, der bei ESC gesetzt werden soll Buttons im Dialog unterstütze ich nur über ein <form method="dialog">. Der Google-Polyfill für Dialoge unterstützt das. Fertig. Danach kannst Du dialog-handler.js anschauen, das ist mein Code. Er lädt bei Bedarf den Dialog-Polyfill von Google nach. DER ist riesig, macht eine Menge, aber das ist eine Blackbox. Es sind ECMAScript-Module, deswegen läuft nichts mit IE - es ist die Frage, ob man das für das Wiki haben sollte. Alles in allem auch nur noch 80 Zeilen, mit Leerzeilen drin und dem dynamischen Laden des Google-Polyfills. Was hältst Du von diesem Ansatz? _Rolf_ -- sumpsi - posui - obstruxi

Hallo JürgenB, ich würde auf einen fertigen Polyfill aus reputabler Quelle verweisen, wie [den hier](https://github.com/GoogleChrome/dialog-polyfill). Der verwendet übrigens eine register-Methode, so wie ich. Und ich hab da nicht abgeguckt 😂 ~~~js if (!window.HTMLDialogElement) { // dialog-polyfill.css hinzufügen // dialog-polyfill.js hinzufügen (manuell, AMD) // ODER dialog-polyfill.esm.js hinzufügen (ES6-import) } ~~~ Und dann kann man sich - unbehindert durch Fragen zum Polyfill an sich - um Dinge kümmern wie Focus-restore oder Button-Steuerung. Beim Google-Polyfill schreiben sie zu dem Thema: > **Focus** > The WAI-ARIA doc suggests returning focus to the previously focused element after a modal dialog is closed. However, this is not part of the dialog spec itself. See [this snippet](https://gist.github.com/samthor/babe9fad4a65625b301ba482dad284d1) to add this, even to the native dialog. Nicht jedes Rad ist so eckig, dass man es neu erfinden muss 😉 Im Firefox klappt die Fokussierung eines Dialog-Buttons übrigens prima, der Fokus wird vom Firefox angezeigt. In Chrome wird der Button durchaus fokussiert, der richtige Button reagiert auf ENTER, aber er zeigt es, solange keine :focus CSS Regel existiert, einfach nicht an! Man muss einmal Tab drücken, dann erst erscheint der Fokus-Rand am Button. Da hilft auch kein setTimeout, sehr merkwürdig. Das ätzende ist, dass man einen fokussierten Button per CSS nicht so stylen kann wie Chrome das ab Werk tut. Buttons in einem Dialog kann man übrigens viel einfacher handeln als mit einer click-Handler Registrierung: Man setzt ein <form method="dialog"> in den Dialog. Klickt man einen Button, wird sein value zum returnValue des Dialogs. Brrr - wieso sagt einem das keiner? Aber mein Dialoghandler kann jetzt beides. Guck mal hierhin: <http://dialog-test.borchmann.one/dialog-test.html>. Einfach nur mal als alternative Möglichkeit. Guck erstmal nur in die dialog-test.html, das ist das, was ein Anwender programmieren und designen würde. Das Öffnen der Dialoge und das Handhaben des Rückgabewertes ist dort implementiert - stupide, für eine Testshell. Spezialitäten meines DialogHandlers: * show/showModal geben ein Promise zurück. Man muss keinen close-Eventhandler registrieren, man hängt sich einfach mit .then an show()/showModal() an. * wer ganz modern ist, baut eine async function und verwendet await, statt mit .then einen Callback zu registrieren. Boah ey 😂. Ist aber nur Syntaxzucker für Promises und .then(). * ich unterstütze ein paar data-Attribute am Dialog: * data-default: Der value des Buttons, der zu Beginn fokussiert sein soll. * data-cancel: Der returnValue, der bei ESC gesetzt werden soll Buttons im Dialog unterstütze ich nur über ein <form method="dialog">. Zuerst hatte ich das selbst gebaut, und dann entdeckt, dass es da was fertiges gibt. Der Google-Polyfill für Dialoge unterstützt das. Fertig. Danach kannst Du dialog-handler.js anschauen, das ist mein Code. Er lädt bei Bedarf den Dialog-Polyfill von Google nach. DER ist riesig, macht eine Menge, aber das ist eine Blackbox. Es sind ECMAScript-Module, deswegen läuft nichts mit IE - es ist die Frage, ob man das für das Wiki haben sollte. Alles in allem auch nur noch 80 Zeilen, mit Leerzeilen drin und dem dynamischen Laden des Google-Polyfills. Was hältst Du von diesem Ansatz? _Rolf_ -- sumpsi - posui - obstruxi