modale Fenster

[1unitedpower]

Das nenne ich nicht "konstruktive Kritik"! Erst etwas bemängeln, dann zugeben, dass Du es nicht ausprobiert hast und dann noch obendrein zugeben, dass das aufgrund der aktuellen Unterstützung durch die Browser ohnehin noch Zukunftsmusik ist. Nee, konstruktiv geht definitiv anders!

Du hast Recht, ich hätte mich intensiver mit deinem Aritkel beschäftigen müssen und bin dir eine ausführlichere Antwort schuldig. Dass man mit einer Kritik auch ihre Limitierungen benennt, halte ich grundsätzlich für guten Stil, aber nichtsdestotrotz ist meine Kritik zu kurz ausgefallen. Dafür möchte ich mich zunächst bei dir entschuldigen.

Ich habe den Test von showModal nachgeholt und bei mir wird der Fokus in dem Dialog gefangen. @JürgenB hat bei seinem Test im Nachbar-Thread allerdings etwas anderes beobachtet, dafür habe ich zur Zeit keine Erklärung. Möglicherweise ist das ein Versionssunterschudied, ich habe mit Chrome 74 getestet.

Auf der anderen Seite musst Du vielleicht überlesen haben, dass ich auf den Wiki-Artikel mit den zugänglichen Dialog-Boxen mehrfach hinweise, in dem die Sache mit der momentanen Notwendigkeit unserer Browser eines Polyfills ja hinlänglich besprochen wird.

Auch damit bist du im Recht.

Dass ich einen "Workaround" gebastelt hätte, verbitte ich mir. Ich spreche konkret von einem Polyfill.

Das war von mir nicht abschätzig gemeint. Workarounds sind ein notwendiges Übel, in deren Entwicklung viel Know-How fließen muss. Polyfills sind auch Workarounds, die dazu dienen (noch) nicht nativ implementierte Features nachzurüsten. Ich hätte das Adjektiv "handgestrickt" aber besser mit einem wertschätzenderen Begriff ausgetauscht.

Wenn der einmal nicht mehr notwendig sein sollte, kann man alles, was mit dem von mir zur Verfügung gestellten Polyfill nicht mehr gebraucht wird, wegkürzen, um nur noch das Handling mit den Callbacks übrig zu lassen.

Vorschlag zur Güte: Du hast ja selber vorgeschlagen den Artikel aufzuteilen, ich glaube das Polyfill wäre eine sinnvolle Schnittmarke und könnte in einem eigenen Artikel untergebracht werden.

Außerdem möchte ich vorschlagen, statt setCallback das native Event-System mit addEventListener zu benutzen. Die Spec definiert für das dialog-Element zwei mögliche Events: close und cancel.

Dafür müssten im Code des Polyfills die folgenden Zeilen gestrichen werden.

    dialog.setCallback = function (key, f) {
      callBacks[key] = f;
    };

    dialog.triggerCallback = function (key) {
      if (typeof callBacks[key] == "function") {
        callBacks[key]();
      }
    };

Und anstelle von dialog.triggerCallback("cancel") müsste der Aufruf wie folgt lauten dialog.dispatchEvent(new Event('cancel')). Ebenso für das open-Event.

Auf der aufrufenden Seite, muss der Aufruf dialog.setCallback('cancel', fn) durch dialog.addEventListener('cancel', fn) getauscht werden.

Ich erinnere Dich hiermit in aller Deutlichkeit an Deine Kritik an Jörgs Login-System-Tutorial, in der Du auch sehr vage und könnte/müsste/würde formuliert hast.

Die Eskalation damals bedaure ich auch heute noch und habe, wie du ja auch weißt, Jörg dafür ebenfalls um Entschuldigung gebeten. Dass meine Kritik zu vage war, weise ich allerdings zurück. Ich habe mich regelmäßig an den Diskussionen um den Artikel beteiligt, dabei habe ich auf mehrere konkrete Sicherheitslücken hingewiesen. Zum Beispiel die Anfälligkeit für Session-Fixation-Angriffe, der Konflikt mit der Apache Implementierung von HTTP Basic Auth und die Verwendung eines Algorithmus für Pseudozufälle anstelle von kryptografisch sicheren Zufallsgeneratoren. Darüber hinaus habe ich mehrfach und ausführlich die schlechte Lesbarkeit des Codes und die Abwesenheit von Qualitätssicherungs-Maßnahmen bemängelt.