Der folgende Text ist ein Gastbeitrag von Mat Marquis. Mat hat eine wichtige PSA (Öffentliche Bekanntmachung) für uns bezüglich responsiver Bilder.
Ich möchte die wichtigste Nachricht nicht verstecken: Wenn Sie eine Version von Picturefill vor Version 2.3.1 verwenden, aktualisieren Sie bitte sofort – aktualisieren Sie Ihre /lib-Dateien, erstellen Sie ein Issue in Ihrem Projekt oder führen Sie ein schnelles npm update picturefill aus und seien Sie beruhigt. Es gab keine Breaking Changes in irgendeiner Version von Picturefill 2, daher sollten Sie beim Aktualisieren keine Probleme haben.
Hier brennt nichts. Picturefill kann keine kritischen Sicherheitsprobleme haben; niemand wird Ihre Megahertz als Ergebnis eines Picturefill-Bugs hacken, oder wie auch immer Hacking im Fernsehen funktioniert. Was dieses Problem für Ihr Projekt bedeuten könnte, sind kaputte Bilder, und was es für Webstandards bedeuten könnte – nun, das hat das Potenzial, ein größeres Problem zu sein.
Das Problem
Bei Verwendung älterer Versionen von Picturefill können in den WebKit Nightly und der Microsoft Edge Vorschau kaputte Bilder angezeigt werden. Dies ist, was wir in der Branche der responsiven Bilder als "ein schlimmes Problem" bezeichnen.
Ein kleiner, aber wichtiger Teil der Spezifikation für responsive Bilder ist die Ergänzung einer currentSrc-Eigenschaft für img, die es uns ermöglicht, die aktuell angezeigte Quelle über JavaScript zu erhalten. Bei der einfachen img der vergangenen Jahre konnten wir immer davon ausgehen, dass der Wert eines src-Attributs die angezeigte Quelle war – es war schließlich die einzige Option für eine Bildquelle. Jetzt, da wir unzählige neue Optionen haben, um Bilder auf verantwortungsvollere und kontextbezogenere Weise bereitzustellen, enthält dieses src-Attribut möglicherweise nicht die Quelle, die dem Benutzer gerade angezeigt wird – daher currentSrc.
Picturefill polyfillt dies, indem es die aktuelle Quelle in eine benutzerdefinierte currentSrc-Eigenschaft schreibt. Browser ohne native Unterstützung für responsive Bilder werden sich daran nicht stören. Die native currentSrc-Implementierung in Browsern ist jedoch schreibgeschützt. Der Kern des Problems ist, dass Picturefill die JavaScript-Deklaration use strict verwendet, was bedeutet, dass Picturefill sehr lautstark auf potenzielle Fehler aufmerksam macht. Die letzten Dinge, die wir wollen, wenn wir versuchen, einen zu 100 % speicherkonformen Polyfill zu erstellen, der *überall* funktioniert, sind stille Fehler. Wenn Picturefill etwas tut, was Browser nicht wollen, möchten wir nicht, dass der Browser eine Ausnahme für uns macht. Wir wollen sofort von dem Problem erfahren und es beheben. In diesem Fall hat der Browser Einwände dagegen erhoben, dass Picturefill versucht, auf eine schreibgeschützte Eigenschaft zu schreiben.
Picturefill verließ sich auf einen Test für die Unterstützung des picture-Elements, um zu entscheiden, ob es überhaupt ausgeführt werden sollte – ein Überbleibsel aus seinen allerersten Versionen. Als die WebKit- und Edge-Vorschauen die Unterstützung für srcset und sizes *ohne* picture einführten, schlug der Test von Picturefill für das picture-Element fehl, sodass versucht wurde, nativ unterstützte Funktionen zu polyfillen. Dies beinhaltete den Versuch, auf currentSrc zu schreiben, was zu einer strict mode-Ausnahme führte. Ausnahmen führen dazu, dass JavaScript stoppt, also stoppte Picturefill – infolgedessen wurden keine Bilder angezeigt, die srcset verwendeten.
Unser Fehler – ehrlich gesagt *mein* Fehler – war, dass wir uns von unserer starken Abstimmung auf native Implementierungen verwöhnen ließen. Lange Zeit hatten wir den Luxus einer klaren Trennung in Bezug auf die Unterstützung responsiver Bilder: Entweder unterstützte ein Browser nur grundlegendes srcset (nur die 1x, 2x „device pixel ratio“-Syntax) oder er unterstützte picture, volles srcset, sizes, das ganze Paket. Da es eine so vorhersehbare Kluft bei der Browserunterstützung gab, funktionierte dies immer einwandfrei – und wenn Dinge einwandfrei funktionieren, denkt man nicht viel darüber nach. Niemand bemerkt, wenn Scharniere nicht quietschen.
Das größere Problem
Das ist schlimm, aber code-seitig leicht zu beheben. Es ist Software; solche Dinge passieren. Das bedeutet nicht, dass solche Probleme auch nur annähernd „in Ordnung“ sind, aber Fehler passieren. Das größere Problem ist der potenzielle *Umfang* des Problems.
Picturefill kam, bevor picture, srcset oder sizes überhaupt in den Köpfen der Browserentwickler waren, und wir nutzten es als Prototyp, um die Spezifikation für responsive Bilder seit dem allerersten Rohentwurf zu informieren. Nachdem es zu einem der ersten echten *Polyfills* für all diese Syntaxen wurde, setzte sich Picturefill riesig durch – eine gewaltige Anzahl von Websites nutzt es. Das macht dies zu einem ernsten Problem, und zwar nicht nur in Bezug auf fehlende Bilder: Wenn dieses Problem in *stabile* Browser gerät und nicht nur in Nightlies und Vorschauversionen, würde es eine *riesige* Anzahl von Websites betreffen.
Aus diesem Grund hat Microsoft Edge die Unterstützung für currentSrc *vorübergehend* entfernt; die erste stabile Version wird srcset und sizes ohne currentSrc ausliefern. WebKit wird dies möglicherweise auch tun. Wenn das Problem jedoch bestehen bleibt, wissen wir nicht, wann diese sehr notwendige Funktion wieder eingeschaltet wird – wenn überhaupt. Anbieter können es sich nicht leisten, dass Hunderte – Tausende – von Websites in ihren Browsern kaputtgehen. Bis wir Picturefill aktualisieren, können wir currentSrc in WebKit oder Edge nicht verwenden – und wenn sie es ganz streichen, könnten die anderen Browser dasselbe tun.
Ernsthaft, bitte Picturefill aktualisieren
Responsive Bilder entstanden wegen uns allen. Nicht die RICG, nicht eine einzelne Person, nicht eine „Kern“-Gruppe einflussreicher Entscheidungsträger für Webstandards – dies sind Funktionen, für die wir Designer und Entwickler gekämpft, *bezahlt* und wahr gemacht haben!
Das Endspiel für einen neuen Webstandard ist jedoch lang. Jetzt, da wir die responsiven Bilder erhalten, nach denen wir so lange gesucht haben, liegt es an uns, alles in die richtige Richtung zu bewegen – und in diesem Fall müssen wir ein wenig Wartung betreiben. Das kann so einfach sein wie die Eingabe von npm update picturefill oder so komplex wie das Kopieren und Einfügen des Inhalts einer Datei – aber in beiden Fällen sind es ein paar Minuten Arbeit. Das gesamte Team für responsive Bilder ist hier, um zu helfen, wenn Probleme auftreten, denn Sie können darauf wetten, dass wir Probleme bei der Aktualisierung auf 2.3.1 sehr genau im Auge behalten, da unsere gesamte Arbeit davon abhängt, dass Picturefill nicht im Weg der nativen Implementierungen steht. Wenn Sie beim Aktualisieren auf Probleme stoßen – obwohl ich nicht glaube, dass das der Fall sein wird –, zögern Sie nicht, mich direkt zu kontaktieren. Das Picturefill-Team – und die gesamte RICG, wenn es sein muss – werden Ihnen helfen, das Problem zu lösen.
Hinweis des Autors: Danke an Alex Jegtnes und Sarah Forst für die Bearbeitung.
Ich hätte nie gedacht, dass ich einen Link zu xkcd auf css-tricks sehen würde. Vielleicht habe ich bis jetzt nicht genau genug hingesehen. Toller Artikel auch.
Die meisten Projekte scheinen immer noch Picturefill 1.x zu verwenden, da 2.x immer noch keine Bilder anzeigt, wenn JS deaktiviert ist. Betrifft dies 1.x?
Kein Problem in 1.X, nein, da dies keine nativen Funktionen polyfillt.
Ich bin neugierig: Wir haben viel mehr Aktivität bei Picturefill 2.X gesehen, aber nur anekdotisch – nichts, was ich leicht belegen könnte. Haben Sie Zahlen zur Nutzung nach Version gesehen/analysiert?
Alternative zu Picturefill ist respimage.
Schauen Sie es sich hier an – https://github.com/aFarkas/respimage
afarkas ist tatsächlich Teil des Picturefill-Teams! Wir haben viele Ideen und Code zwischen den beiden Projekten ausgetauscht, und er übernimmt die Entwicklung der Picturefill 3 Alpha.
Ich liebte die Einleitung :-)
Danach haben Sie gewissermaßen einen Punkt dafür gemacht,
use strict*nicht* in *Produktionscode* zu verwenden…Ich habe diesen Punkt schon früher gehört und könnte mich selbst überzeugen. Für Picturefill möchten wir jedoch lieber einen großen, deutlichen Fehler früh genug sehen, damit wir ihn beheben können, bevor er in einen stabilen Browser gelangt (wie in diesem Fall), als später einen stillen Mystery-Fehler zu riskieren.