Ich habe Code (es ist eigentlich nicht meiner, sondern die SlickGrid -Bibliothek), die ein <style> -Element erzeugt, in das es eingefügt wird Das DOM versucht dann sofort, das neue Stylesheet in der document.styleSheets-Auflistung zu finden.
In WebKit schlägt dies manchmal fehl. Ich habe eigentlich keine Ahnung, was die Umstände sind, aber es ist nichts, das durchweg reproduzierbar ist. Ich dachte mir, ich könnte damit umgehen, indem ich den Code ändere, so dass die Überprüfung für das StyleSheet-Objekt nicht vor dem load -Ereignis für das style-Element erfolgt, wie etwa:
und functionThatExpectsTheStylesheet versucht, das tatsächliche Stylesheet-Objekt wie folgt zu finden:
%Vor%aber manchmal wird das Stylesheet-Objekt selbst zu diesem Zeitpunkt nicht gefunden.
Also, meine Frage ist das:
load -Ereignis tatsächlich nicht, dass das styleSheet-Objekt verfügbar sein wird? Ist es ein Fehler? Das dynamische Laden von CSS-Stylesheets ist leider immer noch ein Bereich voller Browser-Quirks. In Webkit werden die <style> - und <link> -Elemente sowohl als auch die Ereignisse load und error auslösen beim Laden von Stylesheets. Das load -Ereignis selbst bedeutet jedoch nur, dass die Stylesheet-Ressource geladen wurde, nicht unbedingt, dass sie zu document.styleSheets hinzugefügt wurde.
Der require-css RequireJS Loader beschäftigt sich mit diesem Problem, indem er seinen Lademechanismus basierend auf userAgent sniffing verzweigt (es ist fast nicht möglich, zu erkennen, ob das <link> -Tag das load -Ereignis korrekt auslöst oder nicht. Speziell für Webkit greift die Erkennung auf setTimeout zurück, um das StyleSheet -Objekt zu finden wurde an document.styleSheets
Während also das Ereignis load auf Webkit ausgelöst wird, ist es unzuverlässig, um auf die entsprechende StyleSheet -Instanz zugreifen zu können.
Derzeit ist Firefox 18+ das einzige Modul, das Stylesheet load events korrekt unterstützt.
Offenlegung : Ich bin ein Beitrag zu require-css
Referenzen:
Ich denke, das Load-Event könnte früher ausgelöst werden als das CSS-Stylesheet. Das Problem würde vielleicht 1 von 10 Mal passieren, aber es ist immer noch nicht die beste Praxis und der sauberste Weg.
setTimeout ist sicherlich ein guter Ansatz, da sichergestellt werden kann, dass das Skript zuerst das CSS lädt. Da jedoch nur der Tag des Stylesheets, Mittel, die Verbindung zu ihm erstellt wird, müssen die CSS zuerst heruntergeladen werden, so was auch immer Ansatz dieser beiden Sie es verwenden, ist nie 100% ig garantiert, dass Ihre CSS vor dem Load-Ereignis geladen wird feuert.
100% sicher sein, dass alles in der richtigen Reihenfolge ausgeführt wird, eine synchrone Fileread über AJAX, oder einen asynchronen AJAX-Aufruf mit einer Hilfsfunktion zu machen, die überprüft, ob die CSS bereit sind (diese Weise können Sie den Browser einfrieren nicht aber nach wie vor haben die Möglichkeit zu überprüfen, ob die Datei geladen ist oder nicht). Eine andere Möglichkeit wäre, das Stylesheet-Handbuch zu verlinken: Sie setzen zuerst die Stylesheets und dann den Code in der Kopfzeile Ihrer HTML-Datei.
Ich habe nicht sehen so tief in die Last Ereignisse, aber es könnte sein, dass das DOMContentLoaded Ereignis nur feuert wie CSS geladen wird (Abb Forschung auf diesem)
Sehen Sie hier für similiar Frage: jQuery Ereignis, das nach der CSS-Trigger ist geladen?
Ich behaupte nicht, eine Lösung zu haben, weder eine Erklärung des Ladezeitpunkts von Webkit, aber ich hatte kürzlich ein ähnliches Problem, aber mit JS: Ich musste absolut sicher sein, dass das jQuery-Framework geladen wurde, bevor ich andere einschließe eigene Bibliotheken, die von jQuery abhängig waren.
Ich habe dann bemerkt, dass das load -Ereignis von jQuery nicht ausgelöst wurde, als ich es erwartet habe.
Was es wert ist, hier, wie ich mein Problem gelöst habe:
%Vor%Du könntest es versuchen!
Hatte die gleiche Notwendigkeit, die Erkennung für die Stilregel zu verwenden, um zu überprüfen, ob das Stylesheet geladen wurde.
%Vor%Tags und Links javascript jquery dom webkit