Vorgestern fügte die illustre Web Hypertext Application Technology Working Group (WHATWG) ihrer HTML-Spezifikation eine nicht ganz unumstrittene Neuerung hinzu. Es handelt sich um das Attribut srcset zum HTML-Element img. Mit diesem neuen Attribut eines altbekannten Tags soll die Problematik der Steuerung von Bildern in responsiven Layouts einer Lösung zugeführt werden. Einigkeit besteht immerhin darüber, dass das an sich für die Einbindung von Bildern in HTML5 vorgesehene Figure-Tag nicht in der Lage ist, für das sog. Responsive Imaging zu sorgen.
Kontroverse: Picture-Tag oder srcset-Attribut?
Anfang des Monats reichte die W3C Community Group zu Responsive Images unter anderem bei der WHATWG einen Vorschlag zur Standardisierung des hier bereits vorgestellten Picture-Elements ein. Die Antwort der WHATWG nur eine Woche später erscheint eindeutig. Und sie lautet: Nein…
Ein wesentlicher Vorteil des imgsrc-Attributs gegenüber dem Picture-Element liegt aus meiner Sicht auf der Hand. Während das Picture-Element einen relativen hohen Code-Aufwand mit sich brächte und in bestehenden Layouts einen ebenso hohen Änderungsaufwand provozieren würde, ist das imgsrc-Attribut weit schneller zu schreiben und im Zweifel auch zu ergänzen. Zwei Codebeispiele machen das deutlich. Wir beginnen mit dem Picture-Tag:
Und jetzt noch einmal mit dem Attribut imgsrc:
Beide Codebeispiele folgen dem Ansatz Mobile First. Das ist natürlich auch anders möglich. Beide Lösungen lassen sich zudem noch aufbohren. So kann auf das Zooming mobiler Plattformen etwa über den von Apple etablierten Zusatz 2x reagiert werden.
Auch das Picture-Tag verfügt über Vorteile. Das jedenfalls dann, wenn das Standardbrowserverhalten, alle benötigten Assets einer Seite bereits beim ersten Seitenaufruf zu laden (sog. Prefetching) nicht geändert wird. Das IMG-Element gehört zu den Assetlieferanten, die stets vollumfänglich vorab geladen werden. So würden also immer alle Varianten in den Clientbrowser geladen, obschon in der Regel nur eine oder zwei davon benötigt würden. Beim Picture-Element ist Bestandteil der Spezifikation, dass das Laden erst dann erfolgen soll, wenn feststeht, welches Asset benötigt wird. So kann Bandbreite gespart werden.
Andererseits verzögert diese Vorgehensweise den Seitenaufbau und lässt das Surfen langsamer erscheinen. Möglicherweise ist dieser Nachteile jedoch mindestens auf mobilen Geräten weniger schwerwiegend als das komplette Vorausladen großer Bilddateien.
Bis zur Standardisierung ist es noch ein weiter Weg. Man darf gespannt sein, wie sich die Diskussion entwickelt. Man darf dabei allerdings nicht außer acht lassen, dass die WHATWG hochkarätig besetzt ist. Ein Fähnchen im Winde sollte man da nicht erwarten…
Dieter Petereit
Dieter Petereit ist seit 1994 im Netz unterwegs, aber bereits seit über 30 Jahren in der IT daheim. Seit Anfang des neuen Jahrtausends schreibt er für Technik-affine Medien wie T3N und Dr. Web. Dieter war acht Jahre lang Chefredakteur des Dr. Web Magazins.
Broschüren können ein hochwirksames Werbemittel sein, und Ihr Unternehmen oder Ihre Praxis dabei unterstützen, Kunden zu gewinnen. In diesem Text erfahren Sie, wie Sie Ihre Broschüre planen, gestalten und drucken lassen können.
Ein Webdesign selbst erstellen? Ist bei mir schon ewig her. 2006 muss das gewesen sein. Ich durfte für eine Rechtsanwaltskanzlei ran. Typische Erstaufträge. Freundes- und Bekanntenkreis abgrasen eben. Der damalige Freund einer Freundin arbeitete dort und brachte mich ins Spiel.
So ein Designpreis ist eine feine Sache, wenn man ihn auch gewinnt. Insbesondere Werbeagenturen können und wollen auf ihrer Website mit solch einem Preis werben. In der heutigen Aufmerksamkeitsökonomie hat der potentielle Kunde nur eine Aufmerksamkeitsspanne von wenigen Sekunden. Die Verleihung eines Qualitätssiegels, wie das von dem Designpreis Focus Open 2022, kann Dir als Produktdesigner neue Aufträge einbringen. Denn Du darfst damit werben, und platzierst das Gütesiegel natürlich schön prominent auf Deiner Website, sodass es auch jeder innerhalb kürzester Zeit zu Gesicht bekommt. Doch, davor… Nach vielen durchwachten Nächten und kannenweise starkem Kaffee hast Du Dein Produktdesign endlich eingereicht. Nun beginnt das Warten. Trifft Dein Entwurf auf Wohlwollen bei der Jury? Wen aus der Jury muss ich vorher unbedingt noch zu einem Kaffee einladen, um dem Glück auf die Sprünge zu helfen? Wie groß ist die Konkurrenz? Ruhig Blut. Schaue am besten erst einmal auf der Ausschreibungsseite vorbei, lese in Ruhe das Kleingedruckte, und lasse Dich von den Preisträgern der Vorjahre motivieren. Anmeldeschluss ist der 18.3.2022.
0 Antworten
Ich finde das srcset eine grottige Idee. Alleine deshalb, weil die Angabe nicht atomar ist, wie es sonst jedes HTML-Attribut ist. Sieht man mal von Altmüll wie onEvent-Attributen ab. Grenzwertig schon die coords einer Imagemap, aber die stellen wenigstens noch einen zusammengehörigen Datensatz dar. srcset-Angaben sind schlecht parsebar, erst recht mit eingeschränkten Technologien wie XSLT und eine Aufbrechung eines Resource-Tags auf einen Wrapper und mehrere Children hätte auch richtungsweisend in Bezug auf Metadaten von Quellen und damit semantisches Web werden können. Alles in kryptische Attribute zu pressen, ist wenig zukunftsweisend. Was ist mit Chaching, was mit Auflösung, was mit Fehlerverhalten, das darüber vielleicht auch zu steuern wäre? „Totgeburt“ lautet mein Fazit.
Na ja, es verbietet dir ja keiner, eine Anreicherung mit Data-Attributen vorzunehmen, die dann die Flexibilität wieder herstellen würden.
Warum soll das schlecht “parsebar” sein? Ähnliche komplexe Attribute gibt es auch beim SVG. Warum müssen wir alles mit Tags verkomplizieren? Auf der einen Seite, machen wir alles um jedes einzelne Byte zusparen um Seiten schnell und flott für jedes System zumachen und auf der anderen Seite erfinden wir solche komplexen Tagstrukturen. Das Attribut ist vollkommen ausreichend. HTML soll im Quelltext nicht schön aussehen … Ist nur meine Meinung.
Moment, versteh ich das richtig?
Ich konnte der Diskussion jetzt in den letzten Tagen nicht folgen und srcset habe ich nie wirklich ernst genommen.
Aber wenn srcset doch sowieso alle Bilder vorlädt, wieso es dann überhaupt benutzen? Das vorladen aller Bilder ist doch das was man verhindern wollte, oder nicht?
Ich hab aus Picture gehofft und werd dann wohl bei den serverseitigen Lösungen bleiben müssen…
Ich sehe das genauso wie basti1350. Wenn der alles im Vorfeld läd, dann kann ich auch gleich besser bei der Lösung bleiben, eine große Grafik zu laden und dann z. B. auf max-width: 100% herunterzuskalieren. Das wäre jedenfalls performanter als dafür noch zusätzliche Grafiken mitzuladen – spart den Besuchern Traffic und Ladezeit.
eigentlich wär es wesentlich sinnvoller, wenn die entscheidung für diese oder jene bild-datei gar nicht getroffen werden muss, sondern vom bild selbst kommt, wie beispielsweise beim .ico-format. ‘responsive image display’ oder so – es muss natürlich ein geeignetes webkompatibles bildformat erst noch erfunden werden, das sowas beherrscht und nicht mit lästigem lizenzkosten-gegängel wie jpeg2000 daher kommt.
0 Antworten
Ich finde das srcset eine grottige Idee. Alleine deshalb, weil die Angabe nicht atomar ist, wie es sonst jedes HTML-Attribut ist. Sieht man mal von Altmüll wie onEvent-Attributen ab. Grenzwertig schon die coords einer Imagemap, aber die stellen wenigstens noch einen zusammengehörigen Datensatz dar. srcset-Angaben sind schlecht parsebar, erst recht mit eingeschränkten Technologien wie XSLT und eine Aufbrechung eines Resource-Tags auf einen Wrapper und mehrere Children hätte auch richtungsweisend in Bezug auf Metadaten von Quellen und damit semantisches Web werden können. Alles in kryptische Attribute zu pressen, ist wenig zukunftsweisend. Was ist mit Chaching, was mit Auflösung, was mit Fehlerverhalten, das darüber vielleicht auch zu steuern wäre? „Totgeburt“ lautet mein Fazit.
Na ja, es verbietet dir ja keiner, eine Anreicherung mit Data-Attributen vorzunehmen, die dann die Flexibilität wieder herstellen würden.
Warum soll das schlecht “parsebar” sein? Ähnliche komplexe Attribute gibt es auch beim SVG. Warum müssen wir alles mit Tags verkomplizieren? Auf der einen Seite, machen wir alles um jedes einzelne Byte zusparen um Seiten schnell und flott für jedes System zumachen und auf der anderen Seite erfinden wir solche komplexen Tagstrukturen. Das Attribut ist vollkommen ausreichend. HTML soll im Quelltext nicht schön aussehen … Ist nur meine Meinung.
Moment, versteh ich das richtig?
Ich konnte der Diskussion jetzt in den letzten Tagen nicht folgen und srcset habe ich nie wirklich ernst genommen.
Aber wenn srcset doch sowieso alle Bilder vorlädt, wieso es dann überhaupt benutzen? Das vorladen aller Bilder ist doch das was man verhindern wollte, oder nicht?
Ich hab aus Picture gehofft und werd dann wohl bei den serverseitigen Lösungen bleiben müssen…
Ich sehe das genauso wie basti1350. Wenn der alles im Vorfeld läd, dann kann ich auch gleich besser bei der Lösung bleiben, eine große Grafik zu laden und dann z. B. auf max-width: 100% herunterzuskalieren. Das wäre jedenfalls performanter als dafür noch zusätzliche Grafiken mitzuladen – spart den Besuchern Traffic und Ladezeit.
eigentlich wär es wesentlich sinnvoller, wenn die entscheidung für diese oder jene bild-datei gar nicht getroffen werden muss, sondern vom bild selbst kommt, wie beispielsweise beim .ico-format. ‘responsive image display’ oder so – es muss natürlich ein geeignetes webkompatibles bildformat erst noch erfunden werden, das sowas beherrscht und nicht mit lästigem lizenzkosten-gegängel wie jpeg2000 daher kommt.