nicht angemeldet
Matthias Scharwies
Robert B.
JürgenB
Matthias Scharwies
Robert B.
Rolf B
Rolf B
klawischnigg
Rolf B
Rolf B
klawischnigg
Auge
Rolf B
Guten Morgen!
Grad auf css-tricks gelesen: Choice Words about the Upcoming Deprecation of JavaScript Dialogs von Chris Coyier
Chrome hat die Verwendung von alert() in iframes deprecated. Man kann zwar mit
<iframe sandbox="allow-scripts allow-modals ...etc"></iframe>
noch dran vorbei, langfristig sollen alle modalen Dialogboxen wie alert() und confirm() deprecated werden. (Im SELF-Wiki gibt es wohl nur noch wenige Beispiele mit alert().)
Im unteren Teil des Artikels gibt es Stimmen, die das „Don't break the web“-Paradigma in Gefahr sehen.
Herzliche Grüße
Matthias Scharwies
Moin,
was sollen denn die (leichtgewichtigen) Alternativen zu prompt oder confirm sein?
Viele Grüße
Robert
Hallo Robert,
was sollen denn die (leichtgewichtigen) Alternativen zu
promptoderconfirmsein?
evtl. das Dialog-Element. Dann bleiben zwar Firefox und Safari draußen vor, aber das ist ja vielleicht so gewünscht.
Gruß
Jürgen
Servus!
Hallo Robert,
was sollen denn die (leichtgewichtigen) Alternativen zu
promptoderconfirmsein?evtl. das Dialog-Element. Dann bleiben zwar Firefox und Safari draußen vor, aber das ist ja vielleicht so gewünscht.
Nein, alles in JavaScript.
Chris Coyier erwähnt JavaScript/Window/postMessage
What we’ve been told so far, the solution is to use postMessage if you really absolutely need to keep this functionality for cross-origin iframes. That sends the string the user uses in window.alert up to the parent page and triggers the alert from there. I’m not the biggest fan here, because:
- postMessage is not blocking like JavaScript dialogs are. This changes application flow.
- I have to inject code into users code for this. This is new technical debt and it can harm the expectations of expected user output (e.g. an extra <script> in their HTML has weird implications, like changing what :nth-child and friends select).
- I’m generally concerned about passing anything user-generated to a parent to execute. I’m sure there are theoretical ways to do it safely, but XSS attack vectors are always surprising in their ingenouity.
Als zweites wird console.log()genannt. Damit habe ich im Wiki die meisten Live-Beispiele mit einer Ergebnisausgabe realisiert.
Herzliche Grüße
Matthias Scharwies
Moin,
was sollen denn die (leichtgewichtigen) Alternativen zu
promptoderconfirmsein?evtl. das Dialog-Element. Dann bleiben zwar Firefox und Safari draußen vor, aber das ist ja vielleicht so gewünscht.
Nein, alles in JavaScript.
Chris Coyier erwähnt JavaScript/Window/postMessage
Das (also sowohl dialog als auch postMessage) muss dieses KISS-Prinzip sein, oder? Keep It Simple, Stupid. Aber gut, wenn Google meint, dass „Tonnen an Code“ performanter sind, …
Als zweites wird
console.log()genannt. Damit habe ich im Wiki die meisten Live-Beispiele mit einer Ergebnisausgabe realisiert.
Für alert wäre das eine Möglichkeit, für prompt und confirm nicht.
Viele Grüße
Robert
Hallo Matthias,
bei alert kann ich es noch nachvollziehen, das zu verwenden ist oft genug Faulheit. Im Test reicht console.log, und für die produktive Website ist ein alert viel zu hässlich.
Bei confirm und prompt sieht die Sache anders aus. Natürlich kann man Dialoge mit darin liegenden Forms verwenden, um das nachzubauen. Es ist aber deutlich mehr Arbeit (die der Profientwickler bei Google natürlich längst in eine Lib verlagert hat).
Ich stimme Chroyier zu, dass postMessage nicht wirklich eine Alternative ist. Es bedeutet ja, dass die parent page den modalen Dialog für den iframe anzeigen muss. Gerade bei cross-origin iframes, für die die Restriktion zunächst gilt, ist es keine Alternative, denn die geframete Seite weiß ja ggf. gar nicht, dass sie im Frame läuft und rennt unerwartet vor die Wand.
Und die Gründe, die Croyier als Ursache für die Deprecation zitiert, klingen so, als wollte Google Realisierungsprobleme auf die Webdesigner abwälzen.
Leichtgewichtig ist das Alternativprogramm sicher nicht. Aber ein leichtgewichtiges Web scheint nicht mehr das Ziel zu sein 😕
Rolf
und für die produktive Website ist ein alert viel zu hässlich.
Was ist denn „produktiv“?
Wenn zumindest viele Benutzer sofort wissen, was los ist wenn Sie etwas sehen oder wenn es „schön“ ist?
Ich hab mich mal so anlasshalber wie rasch an einem „Replacement“ für alert() versucht:
https://home.fastix.org/Tests/alert_replacement/Alarm_Test.php
Ich bekomme sicher gleich alles um die Ohren gehauen. Versucht ein bisschen lieb zu sein.
Hallo Raktenschnellschießer,
die produktive Stage ist die, auf die man die Anwender loslässt. Davor gibt's die Stages für Abnahmetest, Fachtest und Entwicklung.
Zumindest zwei der vier hast Du auch, wenn Du mehr als Spielerei anbietest.
Warum nimmst Du für Alarm() keinen dialog-Polyfill? Das ist bestimmt im Sinne von Google, weil die einen im Angebot haben.
Rolf
Warum nimmst Du für Alarm() keinen dialog-Polyfill?
Ich wollte was machen, womit ich ohne großes Theater das gute alte alert() ohne großen Aufwand ersetzen kann. Ich hab das in zahlreichen alten Sachen als „Problemmelder“ aber auch für „Erledigt“-Nachrichten verwendet.
Hi there,
Warum nimmst Du für Alarm() keinen dialog-Polyfill?
Ich wollte was machen, womit ich ohne großes Theater das gute alte
alert()ohne großen Aufwand ersetzen kann. Ich hab das in zahlreichen alten Sachen als „Problemmelder“ aber auch für „Erledigt“-Nachrichten verwendet.
Das Problem mit den meisten "alert"-Alternativen (um ehrlich zu sein mit allen, die ich ausprobiert habe) daß bei "alert" ja quasi der Browser einfriert, sprich, das Javascript angehalten wird, bis "ok" gedrückt wird; ein Verhalten, daß die alternativen "alerts" nicht zeigen. (Wie sich das bei Deinem Skript verhält vermag ich nicht zu beurteilen, ich meinen Browsern hat's nicht funktioniert, da hat sich nichts getan, wenn ich auf den "auslösen"-Button gedrückt habe)
Wenn man das nicht braucht, dann hat man mit Sweet-Alert eine recht brauchbare und vor allem vielfältig parametrisierbare Alternative...
Deinem Skript verhält vermag ich nicht zu beurteilen, ich meinen Browsern hat's nicht funktioniert, da hat sich nichts getan, wenn ich auf den "auslösen"-Button gedrückt habe)
Beim IE11 funktioniert es nativ nicht, der hat ein Problem mit dem Defaultvalue in Funktionsaufrufen:
Der Martin
Gunnar Bittersmannfunction foo( bar, baz='Defaultvalue' ) {
Jedenfalls meckert er als einziger das "=" an.
Firefox, Chromium, Chrome, Edge „tun“. Was Du sonst noch für Browser hast wüsste ich gern.
Sweet-Alert
Süß! Hat aber ganz schön viele Kalorien.
Hallo Raketenschnellschießer,
Defaultwerte für Parameter sind nicht die einzige mögliche Lösung.
function schrei(text, okText, focusAfterClose)
{
okText = okText || 'OK';
...
if (focusAfterClose && focusAfterClose.focus)
focusAfterClose.focus();
}
D.h. das Verhalten der JS-Operatoren für || und && beim Umgang mit truthy/falsy-Werten nutzen, um den falsy-Wert undefined gegen 'OK' auszutauschen. Und das zu fokussierende Element kannst Du gleich als Parameter übergeben. Alternativ könnte man auch einen Selektor übergeben statt einer ID und diesen mit querySelector verwenden.
Und statt eines Buttons wäre ein Array richtig. Je Eintrag ein Button.
Die andere Alternative ist ein options-Objekt. Da könnte man dann auch noch einen Callbackhandler unterbringen, der aufzurufen ist, wenn der Dialog geschlossen wird, so dass sich die "Warte auf OK" Funktion von alert nachbilden lässt.
Für modernere Browser kann man auch noch ein Promise zurückgeben. So zum Beispiel:
function Alarm(text, options) {
options = options || {};
options.buttons = options.buttons || [ 'OK' ];
if (Promise)
return new Promise(alarmCore);
else
return alarmCore();
function alarmCore(resolve, reject) {
// tu dies, tu das
function alarmButtonAction(event) {
// fenster schließen
let response = event.target.value;
if (typeof options.success == 'function')
options.success(response);
if (resolve)
resolve(response);
if (options.focusAfterClose) {
if (typeof options.focusAfterClose == 'string')
document.querySelector(options.focusAfterClose).focus()
if (typeof options.focusAfterClose.focus == 'function')
options.focusAfterClose.focus();
}
}
}
}
Alarm("Spam im Forum!", {
buttons: [ 'OK', 'Egal' ],
focusOnClose: '#someElement',
})
.then( btn => if (btn == 'OK') sendmail("Spam im Forum"));
Man kann so ein kleines Dings unglaublich weit ausbauen 😂
Rolf
Alarm("Spam im Forum!", {
buttons: [ 'OK', 'Egal' ],
focusOnClose: '#someElement',
})
Hm. Meine erste Idee für weitergehende Zeug ( Replacement für confirm() ) war sich entweder strikt an das alte confirm() zu halten - oder aber das MsgBox - Zeugs vom M$ nachzustellen (mit „vbYesNo und dem Kram“, also auch identischen Rückgaben).
Unschlagbarer Vorteil: Ich muss nicht eigenes planen und kann die Office-Hilfe mit c&p als Kommentar übernehmen.
Frage: „namespace“ in JS ist „den ganzen Kram“ kurzerhand in einem Objekt zu kapseln? Oder macht man das inzwischen anders?
Hallo Raketenschnellschießer,
Oder macht man das inzwischen anders?
Die Antwort ist die übliche: "Kommt drauf an". Wenn Du aus irgendwelchen Gründen unbedingt etwas im global scope brauchst, dann ja, mach ein Root-Objekt und nenn es Namespace.
Das machen die Client-Scripte von Microsofts ASP.NET beispielsweise so. Die Scripte sind zu verteilt, um das Modulkonzept umsetzen zu können. Und außer <code>Sys</code> haben sie auch nichts im global scope.
JQuery macht das auch. Es gibt $ als globale Variable, der Rest hängt da drunter.
Wenn Du ein isoliertes Stück Code hast, mach ein Modul draus. Entweder auf die klassische Art, oder als ECMAScript-Modul (was in unserem Wiki noch fehlt oder ich finde es gerade nicht).
Ein ECMAScript-Modul hat den Vorteil, dass Du es aus anderen Modulen importieren kannst und es trotz mehrerer Imports nur einmal im System ist. Alles, was Du von dort nicht exportierst, bleibt im Modul isoliert.
Bei klassischen Modulen geht das über einen AMD-Loader wie require.js. Da gibt's eine Menge Patterns, wie man Scripte so schreibt, dass sie mit unterschiedlichen AMD-Loadern funktionieren, aber eins haben sie gemeinsam: Entweder AMD, oder ECMAScript.
Wobei das bei jQuery wieder seltsam ist, der Source ist ECMAScript, aber die Downloads sind AMD. Offenbar transpilieren sie das.
Wenn Du dein Alarm-Modul also als ECMAscript Modul bereitstellen willst, schreibt der Anwender
<script type="module">
import Alarm from './lib/alarm.js';
Alarm("Hilfe!");
</script>
Da Module grundsätzlich deferred geladen werden, spart sie oder er oder they sich damit auch das Warten auf DOMContentLoaded.
Und du schreibst in dein Script am Ende
export default Alarm;
Feddich.
Rolf
Das mit den Modulen schaue ich mir mal an. Ich hoffe, dass auch funktioniert wenn ich hier weiterhin „A+“ haben will.
https://observatory.mozilla.org/analyze/code.fastix.org
(Auch wenn einiges, was man tun muss um das zu schaffen, mangels User-generierten Inhaltes als „ziemlich zweckfrei“ erscheint...)
Hi there,
Firefox, Chromium, Chrome, Edge „tun“. Was Du sonst noch für Browser hast wüsste ich gern.
Ich hab's auf einem XP-Rechner getestet, da gibts schon längere Zeit keine neuen Browser mehr😉
Sweet-Alert
Süß! Hat aber ganz schön viele Kalorien.
Ja, leider, aber dafür gibts keine Dependencies, vor allem braucht man kein jQuery...
Hallo,
Ich hab's auf einem XP-Rechner getestet
ach, und ich dachte, ich wäre so ziemlich der Einzige, der sowas noch hat. 😎
Für die seltenen Momente, in denen ich für irgendwelche Tests doch noch mal ein echtes Windows brauche, keine VM.
Seit meinem Umzug im Sommer 2018 habe ich den aber noch nicht wieder eingeschaltet. Kein Bedarf. Weiß gar nicht, ob die Kiste überhaupt noch funktioniert.
Hmm, da fällt mir ein: Auf der Festplatte dieses Rechners könnte noch ein Backup der mp3-Sammlung von gut 20GB sein, die ich letztes Jahr versehentlich gelöscht habe. Ich war mir eigentlich sicher, dass es außer dem gelöschten USB-Stick noch mindestens eine weitere Kopie gibt ...
da gibts schon längere Zeit keine neuen Browser mehr😉
Dafür aber sehr spannende alte. 😁
Live long and pros healthy,
Martin
Hi there,
Ich hab's auf einem XP-Rechner getestet
ach, und ich dachte, ich wäre so ziemlich der Einzige, der sowas noch hat. 😎
Gibts vermutlich mehrere. Bei mir ist es so, daß ich zum einen ziemlich teuere Hardware in Verwendung hab', für die die Ärs Fuzzies von RME keine Treiber mehr zur Verfügung gestellt haben und zum anderen ist es mir einfach wurscht. Ich verwend' Software solange ich will und nicht bis irgendein Mirkosaftonkel beschliesst, irgendeinen Support (der mich ohnehin nie interessiert hat) einzustellen. Ausserdem, von 20 Rechner die so betreibe ist das (neben einem älteren Laptop) ohnehin der einzige. Sonst ist halt entweder irgendein Linux drauf oder eine neuere Windows-Version (die halt beim Kauf schon dabei war).
da gibts schon längere Zeit keine neuen Browser mehr😉
Dafür aber sehr spannende alte. 😁
Ja eh. Was da d'rauf rennt, das funktioniert überall...😉
Ja, leider, aber dafür gibts keine Dependencies, vor allem braucht man kein jQuery...
Wenn man keine Rechner mit XP unterstützen muss braucht man kein jQuery ...
Ich hab jetzt auch ein Replacement für confirm(). Hab ich YesNo() genannt… Um Promises aus dem Weg zu gehen übergebe ich YesNo() als zweiten Parameter eine Funktion die mit dem Rückgabewert was veranstalten soll (oder halt false).
Ach so: IE 11 geht; 'use strict' ist verbaut.
https://home.fastix.org/Tests/alert_replacement/Alarm_Test.php
Hi there,
Ja, leider, aber dafür gibts keine Dependencies, vor allem braucht man kein jQuery...
Wenn man keine Rechner mit XP unterstützen muss braucht man kein jQuery ...
Ich hab' jQuery noch nie gebraucht.
Ich hab jetzt auch ein Replacement für
confirm(). Hab ich YesNo() genannt… Um Promises aus dem Weg zu gehen übergebe ich YesNo() als zweiten Parameter eine Funktion die mit dem Rückgabewert was veranstalten soll (oder haltfalse).Ach so: IE 11 geht; 'use strict' ist verbaut.
https://home.fastix.org/Tests/alert_replacement/Alarm_Test.php
Sehr gut, funktioniert (IE 11 hab ich nicht) sogar auf meinem Seamonkey 2.42 (aus dem Jahre 2018, das war die letzte Version die noch auf diesem Rechner rennt)...
Ich stimme Chroyier zu, dass postMessage nicht wirklich eine Alternative ist. Es bedeutet ja, dass die parent page den modalen Dialog für den iframe anzeigen muss. Gerade bei cross-origin iframes, für die die Restriktion zunächst gilt, ist es keine Alternative, denn die geframete Seite weiß ja ggf. gar nicht, dass sie im Frame läuft und rennt unerwartet vor die Wand.
Sowie ich den Beitrag verstehe bezieht sich der Vorschlag mit postMessage nur auf den Sonderfall, dass weiterhin der Eindruck entstehen soll, ein Dialog eines iframes gehöre eigentlich zur Elternseite. In dem Fall finde ich es sinnvoll, dass die Entscheidungen darüber, ob und wie Dialoge von Drittanbietern dargestellt werden, bei der einbettenden Seite liegen. Mit postMessage kann die Elternseite iframes eine Schnittstelle anbieten, um Dialoge anzufragen.
Der Regelfall dürfte aber sein, dass die eingebettete Seite ihren eigenen modalen Dialoge öffnet, und nicht das Branding der Elternseite übernehmen möchte. Darauf bezieht sich der Vorschlag mit postMessage aber nicht.
Vielleicht missverstehe ich aber auch etwas, ich verstehe z.B. auch die Passage über dynamisch hinzugefügte <script>-Elemente nicht. Ich sehe nicht, wo man die brauchen sollte.
Und die Gründe, die Croyier als Ursache für die Deprecation zitiert, klingen so, als wollte Google Realisierungsprobleme auf die Webdesigner abwälzen.
Also ich kann sowohl die Bedenken hinsichtlich Sicherheit als auch hinsichtlich Performance gut nachvollziehen. Ich verstehe aber auch auch die geäußerten Bedenken hisnichtlich "don't break the web". Deshalb bin ich auch noch unentschlossen, was ich davon halten soll.
Guten Morgen!
Und die Gründe, die Croyier als Ursache für die Deprecation zitiert, klingen so, als wollte Google Realisierungsprobleme auf die Webdesigner abwälzen.
Also ich kann sowohl die Bedenken hinsichtlich Sicherheit als auch hinsichtlich Performance gut nachvollziehen.
Das man alert() nur noch selten einsetzen sollte, ist imho klar.
Ich verstehe aber auch auch die geäußerten Bedenken hisnichtlich "don't break the web". Deshalb bin ich auch noch unentschlossen, was ich davon halten soll.
Ob ein Browserhersteller entscheiden soll, was richtig und falsch ist, ist glaub ich auch klar. Selbst wenn dieser Konzern mal „Don’t be evil“ als Motto hatte.
Lesetipp: css-tricks: Stay alert! von Robin Rendle
Framework können zerbrechen und verschwinden, das Web selbst mit HTML, CSS und JavaScript sollte abwärtskompatibel bleiben.
Herzliche Grüße
Matthias Scharwies
@@Matthias Scharwies
"don't break the web"
Selbst wenn dieser Konzern mal „Don’t be evil“ als Motto hatte.
Das ist lange her. Heute hat Google wohl das Motto „We are the Web“ und sie tun und lassen was sie wollen.[1]
😷 LLAP
Bis auf die Stellen, wo Facebook und Amazon tun und lassen was sie wollen. ↩︎
Ob ein Browserhersteller entscheiden soll, was richtig und falsch ist, ist glaub ich auch klar.
Die Entscheidung wurde vom WHATWG getroffen.
Framework können zerbrechen und verschwinden, das Web selbst mit HTML, CSS und JavaScript sollte abwärtskompatibel bleiben.
Sollte ja, aber es sollte auch sicher sein, und diese beiden Ziele stehen eben manchmal im Widerspruch. Und dann muss eben abgewogen werden.
@@1unitedpower
Ob ein Browserhersteller entscheiden soll, was richtig und falsch ist, ist glaub ich auch klar.
Die Entscheidung wurde vom WHATWG getroffen.
Framework können zerbrechen und verschwinden, das Web selbst mit HTML, CSS und JavaScript sollte abwärtskompatibel bleiben.
Sollte ja, aber es sollte auch sicher sein, und diese beiden Ziele stehen eben manchmal im Widerspruch. Und dann muss eben abgewogen werden.
Vor ein paar Jahren hat ebendiese WHATWG die Weiterentwicklung von XHTML 2 abgeleht, weil nicht abwärtskompatibel. Just saying.
😷 LLAP
Hallo zusammen,
Sollte ja, aber es sollte auch sicher sein,
ich brauche mal wieder Nachhilfe: Was ist an alert, confirm und prompt gefährlich?
Gruß
Jürgen
Hallo 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.
Ich würde also sagen: Google hat diese Entscheidung getroffen und dem WHATWG eingetrichtert. Möglicherweise wurde das Thema noch auf anderen Ebenen diskutiert, aber im Issue sieht es nach einer relativ einsamen Entscheidung aus.
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. Hier gehen Chrome und Mozilla aber so weit, dass sie für cross-origin iframes die allow-modals Freigabe ignorieren, womit sie Codepen & Co abschießen.
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. Ein weiterer Schritt in der Richtung, Benutzeroberflächen abzudummen und von Inhalt zu befreien, damit bloß keiner von zu viel Inhalt verwirrt ist und das tolle "alles auf einer Seite" Design mit viel Freiraum, parallax scroll und megabyteschweren, aussagefreien Hintergrundbildern genießen kann. ARGH!
Rolf
Hallo Rolf,
danke für die ausführliche Erklärung; ich hatte mich in der Tat auch schon gefragt, was denn an alert() & Co so schlimm sein soll. Dass man die nicht verwenden soll, weil sie vorübergehend den Browser einfrieren, kann ich nachvollziehen; den Zusammenhang mit iframes habe ich dagegen nicht erkannt.
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. Ein weiterer Schritt in der Richtung, Benutzeroberflächen abzudummen und von Inhalt zu befreien, damit bloß keiner von zu viel Inhalt verwirrt ist und das tolle "alles auf einer Seite" Design mit viel Freiraum, parallax scroll und megabyteschweren, aussagefreien Hintergrundbildern genießen kann. ARGH!
100% Zustimmung. Da bemüht man sich um Transparenz, und schon schmeißt einem jemand anders wieder einen Knüppel zwischen die Beine.
Live long and pros healthy,
Martin
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.
Hallo
was sollen denn die (leichtgewichtigen) Alternativen zu
promptoderconfirmsein?evtl. das Dialog-Element. Dann bleiben zwar Firefox und Safari draußen vor, aber das ist ja vielleicht so gewünscht.
Abgesehen von vorhandenen Polyfills ist das ja vielleicht auch ein Tritt in den Arsch, das endlich vollständig zu implementieren.
Das entsprechende Firefox-Issue ist nunmehr über acht Jahre [1] alt. Von den unzähligen „depends on“ sind die meisten bereits geschlossen. Ich habe beim drüberwegscrollen geschätzte sieben oder acht noch offene Abhängigkeiten gefunden, die kein „blocks“ sind.
Mit per about:config manipuliertem dom.dialog_element.enabled habe ich dialog schon benutzt und in einem geschlossenen Benutzerkreis, in dem man die Konfiguration des Browsers bestimmen kann (Intranet), ist das heute schon anwendbar. Es wird mMn aber so langsam Zeit, dass das auch ohne Manipulation per about:config oder in Nightlies funktioniert.
Bei Safari Sieht die Situation ähnlich aus. Das Issue gibt es seit über neun Jahren [2] und auch hier sind noch sechs Abhängigkeiten a.k.a. „depends on“ offen.
Tschö, Auge
Hallo Matthias,
allow-modals
Soweit ich das verstehe, gibt es allow-modals bereits und man muss es setzen, wenn man einem sandboxed iframe modale Dialoge erlauben will (alert, confirm, prompt, print).
Die Abfrage auf cross-origin steht in der Spec für sich, und sie greift unabhängig von allow-modals. In meiner Chrome-Installation passiert es noch nicht.
Das Thema wurde in einem Github-Issue diskutiert und dann beschlossen. Nachdem die Änderung aktiv war, gab es prompt Gemaule von Leuten, deren Seiten kaputtgingen. Reaktion: "whatwg locked as too heated and limited conversation to collaborators 5 days ago"
Bitte was? Ihr macht das Web kaputt und die, die sich beschweren, bekommen einen Maulkorb? Unter "too heated" verstehe ich was anderes als das, was da geschrieben wurde...
Rolf