In diesem Beitrag werde ich über die Polyfill-Bibliothek für HTML5- und CSS3-Funktionen namens Webshims Lib sprechen und wie man sie richtig verwendet.
Polyfill?
In der Webentwicklung nennen wir Skripte, die Teile der HTML5- oder CSS3-Spezifikation emulieren, „Polyfills“. Ein Polyfill kann fast alles sein – eine JavaScript-Bibliothek, die Unterstützung für CSS3-Selektoren zu älteren Versionen von Internet Explorer hinzufügt (z. B. Selectivizr) oder eine High-End-Flash-basierte Lösung, um die Tags <audio> und <video> bis zurück zu IE 6 zu aktivieren (z. B. html5media).
Webshims vorstellen
Die Webshims Lib ist eine der umfassendsten Polyfills, die es gibt. Sie basiert auf jQuery und Modernizr. Durch das Einbinden dieses *einen* Skripts werden viele Funktionen in allen gängigen Desktop-Browsern aktiviert.
Webshims ermöglicht HTML5- und CSS3-Funktionen wie semantische Tags, Canvas, Web Storage, Geolocation, Formulare und Multimedia. Wenn man diese lange Liste liest, kommt einem vielleicht als Erstes in den Sinn, wie riesig diese Bibliothek sein muss. Das bedeutet eine riesige Downloadgröße und lange Skriptausführungszeiten. Aber hier ist der Clou: Webshims erkennt automatisch, welche Funktionen der Browser des Benutzers unterstützt, und lädt nur das, was zur Simulation aller anderen notwendig ist. So werden Benutzer, die bereits einen modernen Browser wie Firefox oder Chrome verwenden, nicht verlangsamt. Sie können sogar die Menge der zu ladenden Funktionen reduzieren, wenn Sie nicht alles benötigen.
Webshims verwenden
Um die Webshims-Bibliothek zu verwenden, müssen Sie die Abhängigkeiten jQuery und Modernizr zusammen mit Webshims Lib einbinden.
<script src="scripts/jquery-1.8.2.min.js"></script>
<script src="scripts/modernizr-custom.js"></script>
<script src="scripts/webshim/polyfiller.js"></script>Jetzt müssen Sie WebShims initialisieren und, falls erforderlich, ihm mitteilen, welche Funktionen Sie verwenden möchten.
<script>
// Polyfill all unsupported features
$.webshims.polyfill();
</script><script>
// Polyfill only form and canvas features
$.webshims.polyfill('forms canvas');
</script>Und das ist alles! Webshims erkennt und polyfillt fehlende Funktionen automatisch je nach Browser des Benutzers. Wenn Sie neugierig sind, ist die vollständige Liste der Funktionen:
- json-storage
- es5
- geolocation
- canvas
- Formulare
- forms-ext
- mediaelement
- track
- details
Beispiel
Machen wir ein Beispiel mit dem Tag <video>. Zuerst erstellen wir die grundlegende Seite ohne Webshims oder andere Polyfills.
<!DOCTYPE html>
<html>
<head>
<title>Video native</title>
</head>
<body>
<video width="480" height="360" controls="controls">
<source src="Video.mp4" type="video/mp4">
<source src="Video.webm" type="video/webm">
</video>
</body>
</html>Moderne Browser werden dieses Video korrekt anzeigen, aber Internet Explorer 6, 7 oder 8 nicht.
Jetzt ändern wir das Beispiel, um die Webshims Lib einzubetten. Sie sehen, dass es nicht notwendig ist, sonst etwas zu ändern.
<!DOCTYPE html>
<html>
<head>
<title>Video including polyfill</title>
<script src="scripts/jquery-1.8.2.min.js"></script>
<script src="scripts/modernizr-custom.js"></script>
<script src="scripts/webshim/polyfiller.js"></script>
<script>
$.webshims.polyfill('mediaelement');
</script>
</head>
<body>
<video width="480" height="360" controls="controls">
<source src="Video.mp4" type="video/mp4">
<source src="Video.webm" type="video/webm">
</video>
</body>
</html>Der moderne Browser wird seinen nativen <video>-Player anzeigen, aber jetzt ist diese Funktionalität auch in Internet Explorer 6+ verfügbar. Sie können die Demo hier ausprobieren.
Fazit
Wie das Beispiel gezeigt hat, ist die Verwendung der Webshims Lib wirklich einfach. Es ist nicht notwendig, Ihren Code zu ändern, und es verlangsamt keine Benutzer, die einen modernen Browser verwenden. Es ermöglicht jedem, alle Funktionen zu genießen, die Ihre Seite bietet. Besuchen Sie die Webshims-Homepage für den Download, die Dokumentation und weitere Demos.
Dies ist eine wirklich coole und nützliche Bibliothek. Danke fürs Teilen!
Der gesamte Code zeigt nicht umbrechende Leerzeichen-HTML-Entitäten. Macht es ein wenig schwer zu lesen!
Interessant! Einerseits spricht Christian Heilmann vom Vanilla-Web-Diät zur Vereinfachung des Webs und andererseits haben wir Polyfills zur Unterstützung aller anderen Funktionen auf allen möglichen Browsern der Welt…
Endlich ein „All-in-One“-Polyfill/Skript, um IE korrekt zum Laufen zu bringen. Gut, dass ich css-stricks.com abonniert habe :)
Zwei Fragen zu Ihrem Beitrag
1- Warum zeigen Ihre Codebeispiele
und&? Wenn es eine Möglichkeit gibt, dies zu beheben, wäre das großartig, damit wir die unnötige Markup nicht „aussortieren“ müssen.2- In Ihrer HTML-Struktur empfehlen Sie jetzt, die Skripte im
<head>-Bereich hinzuzufügen. Wir alle wissen, dass dies keine empfohlene/beste Vorgehensweise ist.Ich sehe jedoch, dass *Webshims Lib* von der Ladung von jQuery und Modernizr abhängig ist, aber normalerweise geht Modernizr in den
<head>, während jQuery so nah wie möglich am schließenden</body>-Tag platziert wird.Ist die Ladereihenfolge von jQuery und Modernizr zwingend erforderlich, damit diese *Webshims Lib* funktioniert?
Ich denke, es ist wichtig, dass Sie diese Punkte bei der Erstellung eines Beitrags wie diesem „Wie man es richtig benutzt“ berücksichtigen.
Der Abschnitt readme.md auf Github dieses Skripts hilft auch nicht viel.
Danke.
Nun, egal wegen Frage #1, es scheint, dass Sie sie jetzt behoben haben. Danke :)
Die Ladereihenfolge ist offensichtlich wichtig (da webshims *auf* jQuery aufbaut), aber ich sehe nichts, was darauf hindeutet, dass sie im <head> erfolgen muss.
Die Github-README besagt, dass Sie warten müssen, bis das Dokument fertig geladen ist, bevor Sie *irgendwelche* der polyfillten Funktionen *verwenden* (was sowieso eine gute Beratung ist), deutet aber auch an, dass Sie *nicht* warten müssen, um
$.webshims.polyfill()aufzurufen.Angesichts dessen würde ich vermuten, dass es völlig in Ordnung ist, alles am Ende der Seite zu platzieren (oder in einem
onload-Ereignis im <head>, was im Grunde das gleiche Ziel erfüllt).Danke für die großartige Erklärung von Polyfills.
Allerdings funktioniert die Videodemo für mich in IE7 oder IE8 nicht. Funktioniert sie für jemand anderen?
ps. Ich benutze einen Mac mit Virtualbox und den VMs, die Microsoft für IE-Tests bereitstellt. Vielleicht ist mein Setup doch keine gute Testumgebung?
Ups. Ich meinte, „Allerdings funktioniert *die* Videodemo…“.
echtes IE7 – **nein**
echtes IE8 – **ja**
IE7 = Nein
Win 7 mit Virtual Box (Vista)
Donnerstag ist wohl das neue Montag
Flash auf der virtuellen Maschine geladen, wie Alexander Farkas unten vorgeschlagen hat, und das Video spielt.
Mein Fehler
Verdammt! Das war mein Problem. Musste nur Flash auf meinen VMs installieren. Deshalb liebe ich diese Seite: Schritt 1: Meine Ignoranz zur Schau stellen. Schritt 2: Dinge lernen. Danke.
Vielleicht eine dumme Frage, aber ersetzt das Modernizr oder geht es damit einher? D.h. Muss ich beide Skripte einbinden?
@D
Nein, es ist eine Ergänzung zu Modernizr. Modernizr ist das beste Feature-Detection-Skript der Welt. Webshims baut darauf auf, um die Polyfills zu erstellen.
@traq
Demo funktioniert bei mir in echtem IE6/7/8 (man braucht natürlich Flash).
@Ricardo
Die Ladereihenfolge ist entscheidend, aber Sie können natürlich jQuery + Webshims am Ende Ihrer Seite hinzufügen. Aber kurz gesagt, ich glaube nicht, dass dies immer eine gute/beste Praxis ist. Es gibt wirklich viel zu dieser Regel zu sagen und es ist nur ein Workaround. Eigentlich halte ich es oft für schlechte Praxis, JS am Ende zu platzieren. Wenn Ihr JS für die Benutzeroberfläche und Funktionalität Ihrer Seite entscheidend ist, sollten Sie es (blockierend) aus dem Head laden, wenn es nicht so wichtig ist, sollten Sie es asynchron aus Ihrem Head laden (entweder mit dem async-Attribut oder einem Skript-Loader) und wenn es nur ein paar Extras hinzufügt (Lightbox), können Sie es asynchron + verzögert (onload/domready) aus Ihrem Head laden. Sie sollten auch bedenken, dass diese Regel in einer Ära von IE6/IE7 eingeführt wurde. Zu dieser Zeit blockierte das Hinzufügen eines Skripts oben nicht nur das Rendern der Benutzeroberfläche, sondern erzwang auch den sequenziellen Download. Das hat sich seitdem geändert und Webshims lädt die Polyfills immer asynchron. (Die Kombination aus asynchronem Laden + verzögertem Laden erhöht FOUCs, ohne Ihnen einen großen Geschwindigkeitsvorteil zu verschaffen).
@Daniel
Vielen Dank für diesen Beitrag!
hmm.. welche Version von Flash wird benötigt?
Nun, ich muss sagen, dass ich mehreren Ihrer Kommentare entschieden widerspreche. Aber ich habe auch einige Fragen, da Sie mehrere interessante Dinge erwähnen
1.- *„[…] jQuery + Webshims am Ende meiner Seite hinzufügen. Aber kurz gesagt, ich glaube nicht, dass dies immer eine gute/beste Praxis ist.“* – Ich bin mir nicht sicher, warum Sie das Platzieren von Skripten am Ende nicht für eine gute Praxis halten, viele Leute tun es: HTML5 Boilerplate, 320 And Up usw., um nur einige zu nennen. Wenn Yahoo-Entwickler es mit guten Begründungen empfehlen, bin ich mir nicht sicher, warum Sie gegen diese Praxis sind.
Ich persönlich mache es und werde es weiterhin tun, weil es aus technischen, Performance- und SEO-Gesichtspunkten sinnvoll ist.
2.- *„[…] es ist nur ein Workaround“* – Ein Workaround wofür? Vielleicht übersehe ich etwas, aber ich sehe nichts, was umgangen werden muss, indem die Skripte am Ende platziert werden.
3.- *„Wenn Ihr JS für die Benutzeroberfläche und Funktionalität Ihrer Seite entscheidend ist, sollten Sie es (blockierend) aus dem Head laden“* – Mit den heutigen JavaScript-Funktionen und der Tatsache, dass jQuery die Lernkurve so stark gesenkt hat, würde ich sagen, dass fast jedes JavaScript entscheidend für die Benutzeroberfläche und Funktionalität unserer Seiten ist. *Webshims* ist ein klares Beispiel dafür.
Dennoch sehe ich keinen Vorteil darin, alle Skripte wieder im
<head>-Bereich zu laden, im Vergleich zu dem, was wir bereits als beste Praxis kennen, sie am Ende des Markups zu laden.4.- *„[…], laden Sie es asynchron aus Ihrem Head (entweder mit dem async-Attribut… […] Sie können es asynchron + verzögert laden“* – Frage: Haben Sie noch nie etwas vom asynchronen Laden von Skripten oder mit einem Skript-Loader oder „verzögert“ gehört? Ich bin kein JavaScript-Entwickler/Guru. Können Sie dazu mehr sagen? Vielen Dank im Voraus.
5.- *„Sie sollten auch bedenken, dass diese Regel in einer IE6/IE7-Ära eingeführt wurde.“* – Wir befinden uns immer noch in dieser Ära, Alexander. Der einzige Unterschied ist, dass wir fortgeschrittenere Browser haben, aber IE6 und IE7 sind immer noch sehr präsent.
Darüber hinaus hat die Empfehlung von Yahoo-Entwicklern, Skripte am Ende des Markups zu platzieren, nichts mit IE zu tun. Daher bin ich mir nicht sicher, wie Ihre Aussage gerechtfertigt ist.
6.- *„Zu dieser Zeit blockierte das Hinzufügen eines Skripts oben nicht nur das Rendern der Benutzeroberfläche, sondern erzwang auch den sequenziellen Download.“* – Sie haben Recht damit, dass das Hinzufügen von Skripten oben (<head>) das Rendern der Benutzeroberfläche blockiert. Daher widersprechen Sie sich gerade, da Sie sagten: *„Wenn Ihr JS für die Benutzeroberfläche und Funktionalität Ihrer Seite entscheidend ist, sollten Sie es (blockierend) aus dem Head laden.“*
Andererseits erfolgt der sequenzielle Download, egal wo Sie Ihre JavaScripts platzieren, im <head> oder am Ende des Markups. Es sei denn, ich bin mir über das Laden von JavaScripts nicht bewusst.
Ich weiß nicht, was *„zu dieser Zeit“* bedeutet. Sequenzielle Downloads gibt es schon seit der Erfindung dieser „Maschine“.
7.- *„Das hat sich seitdem geändert und Webshims lädt die Polyfills immer asynchron.“* – Was hat sich „seitdem“ geändert, wenn Sie gerade sagten: *„Zu dieser Zeit…“*? Ein weiterer Widerspruch. Es ist irgendwie schwer, Ihre Ideen zu verstehen…
8.- Und ein letzter Widerspruch: In Ihrer letzten Aussage sagen Sie, dass *„(die Kombination aus asynchronem Laden + verzögertem Laden erhöht FOUCs, ohne Ihnen einen großen Geschwindigkeitsvorteil zu verschaffen)“*, aber oben haben Sie gerade empfohlen, dies zu tun: *„[…], sollten Sie es asynchron aus Ihrem Head laden (entweder mit dem async-Attribut… […] Sie können es asynchron + verzögert laden“*.
Was FOUC betrifft, so sehe ich das persönlich nicht als großes Problem. Ja, es ist ärgerlich, aber das ist die Natur der Sache und es ist nur eine Frage der Zeit, bis wir nicht mehr darüber nachdenken müssen, so wie wir nicht mehr über
-moz-border-radiusnachdenken (es sei denn, Sie verwenden ein Mixin, das es automatisch in Ihr kompiliertes CSS einfügt).Meine Schlussfolgerung aus all dem ist einfach
A. Es gibt keine Begründung, JavaScripts nicht weiterhin am Ende des Markups zu platzieren. Natürlich ist die richtige Ladereihenfolge/Stapelreihenfolge zwingend erforderlich, aber dennoch ist das Platzieren am Ende absolut in Ordnung und immer noch eine beste Praxis.
B. Wir befinden uns immer noch in der IE6/IE7-Ära. Ich kann den Tag kaum erwarten, an dem ich (wir) diese Charaktere nicht mehr berücksichtigen müssen :)
C. Ich habe keine Ahnung, was *asynchrones Laden* oder *verzögertes Laden* oder *ein Skript-Loader* sind oder wie sie funktionieren. Wenn Sie oder jemand anderes Informationen dazu hat, die Sie teilen könnten, wäre das großartig.
D. Ich wünschte, ich könnte dieses Gespräch persönlich führen, da ich nie auf diesem Niveau mit jemandem reden kann, nicht einmal dort, wo ich arbeite. Ich bin sicher, es gibt vieles, was ich von Ihnen und Ihrer Arbeit lernen muss.
Ich werde *Webshims* jetzt zu meiner Webdesign-Werkzeugkiste hinzufügen :)
Danke.
A. Es gibt keine Begründung, JavaScripts nicht weiterhin am Ende des Markups zu platzieren. Natürlich ist die richtige Ladereihenfolge/Stapelreihenfolge zwingend erforderlich, aber dennoch ist das Platzieren am Ende absolut in Ordnung und immer noch eine beste Praxis.
Das gibt es mit Sicherheit. Ich habe keine Ahnung, welche Plattformen und Arten von Benutzern Sie unterstützen, aber 90% des Codes, mit dem ich arbeite (der nicht von mir geschrieben wurde), lädt 95% des JavaScripts im Head. Wenn ich mich als Entwickler mit Ladereihenfolgen befassen muss, muss ich auch im Head laden, sonst breche ich Dinge.
B. Wir befinden uns immer noch in der IE6/IE7-Ära. Ich kann den Tag kaum erwarten, an dem ich (wir) diese Charaktere nicht mehr berücksichtigen müssen :)
Es tut mir leid für Sie. Das tut es wirklich. Ich muss mich seit zwei Jahren nicht mehr mit IE7-Unterstützung auseinandersetzen. IE8-Probleme treten nur auf, wenn ein Kunde explizit IE8-Kompatibilität wünscht. Können Sie es nicht erwarten, dass die Unterstützung für mittelalterliche Browser endet? **Dann hören Sie auf, sie zu unterstützen!** Indem Sie sie weiterhin unterstützen, unterstützen Sie das Problem. Viele von uns hatten bereits *dieses* Gespräch mit Vorgesetzten, Kunden usw. Ich empfehle Ihnen, dasselbe zu tun und ihnen überzeugende Gründe zu nennen, warum alte Browser eine unglaubliche Verschwendung von Zeit, Ressourcen und letztendlich Geld sind. Wenn sie Ihnen nicht zuhören, sind Sie nicht überzeugend. Wenn Sie darauf warten, dass Unternehmensnutzer zu modernen Browsern wechseln, werden Sie immer weiter warten.
C. Ich habe keine Ahnung, was asynchrones Laden, verzögertes Laden oder ein Skript-Loader sind oder wie sie funktionieren. Wenn Sie oder jemand anderes Informationen dazu hat, die Sie teilen könnten, wäre das großartig.
Es gibt viele Informationen zum asynchronen Laden. Ich finde es etwas hochnäsig, dass Sie dem Autor sagen, seine Meinungen seien falsch, obwohl Sie selbst zugeben, dass Sie „kein JavaScript-Guru“ sind.
D. Ich wünschte, ich könnte dieses Gespräch persönlich führen, da ich nie auf diesem Niveau mit jemandem reden kann, nicht einmal dort, wo ich arbeite. Ich bin sicher, es gibt vieles, was ich von Ihnen und Ihrer Arbeit lernen muss.
Das ist nicht überraschend.
Aber wenn ich es richtig verstehe, wird das Polyfill auch in den Browsern geladen, die native Unterstützung für die von Ihnen polyfillten HTML5- oder CSS3-Funktionen haben?
Oder kann oder sollte man es sogar mit Modernizr.load yep/nope laden?
„Webshims erkennt und polyfillt fehlende Funktionen automatisch je nach Browser des Benutzers.“
Entschuldigung… Ich hätte besser lesen sollen, bevor ich meine Frage gestellt habe.
Dieses Video wurde für mich in IE 6 – 8 abgespielt. Beeindruckend!
@Ricardo
Wenn andere Leute von einer Klippe springen, springen Sie ihnen hinterher? „Aber andere Leute tun es auch“ ist kaum ein valides Argument.
Die Entwickler von Yahoo trafen diese spezielle Empfehlung zu einer Zeit, als asynchrone Skript-Loader nicht existierten, Ressourcen immer noch asynchron angefordert wurden, der durchschnittliche Webserver und Web-Proxy keine ordnungsgemäßen Cache-Header mit zukünftiger Gültigkeit setzten usw.
Wir haben einen Namen dafür, diese Art von Empfehlungen blind zu befolgen, ohne ihre Gültigkeit regelmäßig neu zu bewerten: Man nennt das Cargo-Kult-Programmierung.
RequireJS wäre etwas Nützliches, um es zu lesen und zu lernen. Es ist ein Skript-Loader, der den aufkommenden Standard für asynchrone Moduldefinition (AMD) von CommonJS verwendet.
Keine Beleidigung, aber bei den < 2% Browseranteil, den ich üblicherweise sehe, würde ich mich nicht an alte Cargo-Kult-Praktiken halten, um die Geschwindigkeit für eingeschränkte, unterentwickelte Browser zu optimieren, die höchstwahrscheinlich auf veralteter Hardware laufen und schnell ihrem Ende entgegentreten.
Sie sind sich der Tatsache nicht bewusst, dass IE8+ und jede zeitgemäße Version der anderen wichtigen Browser Skripte parallel herunterladen. Nur die Ausführung erfolgt immer noch sequenziell (und man kann das sogar ausschalten…)
OFFTOPIC--
Die „Klippen“-Analogie, lol. Ich bin mir sicher, dass ich dafür ziemlich alt bin :p
Ich springe sicherheitshalber „nicht“ ab, tatsächlich springe ich gar nicht, und wenn ich springen würde, würde ich mit vielen der „großen Jungs“ springen.
Cargo-Kult-Programmierung, verstanden, ergibt total Sinn: Ich bin kein Programmierer. Trotzdem interessant.
Ja, Require.js, ich habe viel darüber gelesen, aber einige seiner Konzepte nicht wirklich verstanden. Jetzt habe ich eine bessere Vorstellung davon, was das ist.
Keine Beleidigung, Ron. Sie und ich sind im selben Boot und teilen die gleiche Ansicht. Allerdings ist der Anteil, den ich üblicherweise sehe, weitaus höher als Ihrer. Ich muss sagen, dass ich für IE6 nichts mehr tue und definitiv so hart wie möglich daran arbeite, den zusätzlichen Aufwand für IE7 zu minimieren.
Ich glaube nicht, dass IE6/IE7 einem schnellen Tod entgegentreten, im Gegenteil, wir haben alle ihre immens langsamen Tode erlebt.
Ja, ich war mir nicht bewusst, dass moderne Browser Skripte parallel herunterladen. Ich habe kürzlich einiges über diesen parallelen/sequenziellen Download von CSS bei der Verwendung von
@importim Vergleich zulinkgelernt, aber es wurde nichts über den parallelen/sequenziellen Download von Skripten besprochen.Jetzt weiß ich es.
Danke für die Infos, sehr hilfreich.
Mist; das sollte heißen: „wurden immer noch **synchron** angefordert.
Ich habe nur IE9 (nicht meinen normalen Browser), und wenn ich im Browser-Modus: IE7/8/9-Kompatibilität laufe, hat es nicht funktioniert…
Aber dann habe ich nachgesehen und festgestellt, dass Flash für IE nicht installiert war… :-)
Installiert, und es funktioniert wie am Schnürchen, tolle Entdeckung!
Atg
@Ricardo Zea /offtopic
Zum asynchronen und normalen Ladeverhalten von JS. Normalerweise können Browser 2-8 Dateien gleichzeitig pro Domain laden (alte Browser wie IE6/7 oder FF3.0 laden 2, andere 4-8). Und das parallele Laden von Dateien ist offensichtlich viel schneller als sequenziell.
Der Grund für die Regel „JS am Ende platzieren“ ist der folgende
Sobald Sie normalerweise ein Skript[src] zu Ihrem HTML hinzufügen, blockiert es Ihren Browser daran, folgende Aufgaben auszuführen:
a) Andere Ressourcen herunterladen (nur wahr für IE6/IE7, IE8 begann dies zu ändern und IE9 und andere Browser sind hier extrem gut)
b) HTML in DOM parsen (nur wahr für IE6/IE7)
c) UI rendern (alle Browser)
Das Platzieren von JS am Ende minimierte also das Problem, da keine anderen Download-Ressourcen blockiert werden können und das DOM + UI zu 99% geparst/gerendert ist.
Diese Regel wurde zu einer Zeit eingeführt, in der alle Browser alles blockierten. Wie Sie sehen können, ist a) und b) nur für IE6/IE7 wahr und nur Punkt c) ist in allen Browsern vorhanden (und wird sich nicht ändern, da dies die Funktionsweise von Browsern ist). Das Nicht-Blockieren des UI-Renderings bedeutet immer, dass Sie einen FOUC erstellen. Das ist wirklich wichtig zu verstehen. FOUCs sind keine Nebenwirkung der Regel „JS am Ende platzieren“, sie sind beabsichtigt. Denn Sie sagen damit als Entwickler: Mein JS ist für die Benutzeroberfläche nicht wichtig, machen Sie die JS-Sachen lieber am Ende.
Das asynchrone Laden von Skripten ist eine wirklich schöne Technik, um Probleme a, b und c in allen Browsern (auch in IE6/7) zu vermeiden, während Sie bessere Kontrolle über das FOUC-Problem haben. Der Punkt ist: Sobald Sie asynchrones Laden verwenden, wird nichts blockiert, aber da Sie den Skript-Download bereits im Head-Element starten können, kann das Skript viel früher heruntergeladen, geparst und ausgeführt werden, und wenn es sich im Cache des Clients befindet, erzeugen Sie keinen FOUC/FOUBC.
Mit verzögertem Laden meine ich einfach, dass Sie das asynchrone Laden eines Skripts verzögern können (nach einem Timeout, nach domready oder nach onload), wenn dieses Skript für Ihre Benutzeroberfläche nicht wichtig ist (z. B. Lightbox). Diese Technik kann hilfreich sein, denn obwohl Sie nicht-blockierende Skriptlade-Techniken verwenden, verbraucht das Laden eines Skripts eine HTTP-Anfrage, die stattdessen für ein Inhaltsbild verwendet werden könnte.
Das einzige Problem beim asynchronen Laden ist die Tatsache, dass die Ausführung Ihrer Skripte nicht mehr geordnet ist und dies zu Race Conditions führen kann. Webshims lädt alles asynchron (ohne Blockierung) und behandelt das Race-Condition-Problem sehr effizient (ähnlich wie RequireJS).
Großartige Erklärung, Alexander, vielen Dank.
Ich bin mir nicht sicher, wie ich Chris' Beitrag „Thinking Async“ übersehen habe, ich werde ihn lesen, sobald ich diese Antwort geschrieben habe.
Jetzt, mit Ihren und Rons Erklärungen oben, bin ich sicher, dass ich nicht der Einzige bin, der überdenkt, wo/wie Skripte in meinem Markup platziert werden, da ich jetzt neue Informationen und Gründe habe, dies zu überdenken. Hmm… das klingt, als würde ich mit Ihnen beiden von einer Klippe springen, lol.
Ich bin sicher, dass kein Programmierer bei mir zu Hause irgendwelche Ahnung von dem hat, was wir hier bezüglich Browser, asynchronem und verzögertem Laden von Skripten besprochen haben. Daher werde ich sie sicher über ein paar neue Dinge informieren.
Nochmal vielen Dank für all die Informationen, sehr hilfreich.
@traq
Flash benötigt Version 9.0.115, um h.264-Videos abzuspielen.
Kann *Webshims* mit HeadJS anstelle von Modernizr verwendet werden?
Im Moment nicht. Es hängt von den Bibliotheken Modernizr & jQuery ab.
Kann dies verwendet werden, um auch SVG zu aktivieren?
Heißes Drama!!!! Ich hoffe, @ChrisCoyier wird bald ein Screencast darüber veröffentlichen, wo und wann man sie laden soll.
Wird das mit jQuery 2.0 funktionieren, sobald es alte IE-Versionen nicht mehr unterstützt?
ernsthaft Chris, du hast mich verloren, mehr als eine Sache kann ich nicht verstehen.
Nützlicher Code und sehr interessant, ich glaube, ich brauche auch einen Coding-Touch, um das zu verstehen.
Nun…. es hat ein Problem behoben, bei dem Safari die HTML5-Validierung nicht unterstützt (Twitter Bootstrap).
Und ich schätze, IE8 wird einfach immer IE8 sein. Ich mochte nie irgendetwas an Microsoft.
Vielen Dank für das Tutorial.
Danke für die großartige Erklärung.
Ich bin nur neugierig, ob wir yesNope.js verwenden können, um unseren eigenen Polyfill für Features einzubetten, die nicht in der Webshim-Bibliothek vorhanden sind. Oder gibt es einen anderen Weg, ihn einfach mit Webshim selbst einzubetten. Oder wenn ich yesNope.js verwende, wie sieht es mit der Performance aus?
Vielen Dank im Voraus.