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.
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.
Farben spielen im Design natürlich eine große Rolle. Doch stimmige und passende Farbkonzepte zu erstellen, ist nicht jedermanns Sache. Daher gibt es eine Reihe von Webanwendungen, die dir helfen, gute Farbkombinationen zu finden. Monochromatische Farben lassen sich ebenso zusammenstellen wie Komplementärfarben. Dabei unterscheiden sich die Tools teils bereits im Ansatz.
Responsives Webdesign ist bereits seit längerer Zeit in aller Entwickler Munde. Eine responsive Website gilt sozusagen als die eierlegende Wollmilchsau, denn sie funktioniert auf jedem Ausgabegerät und mit jeder denkbaren Bildschirmauflösung. Egal, ob du eine Website auf einem Smartphone, einem Tablet oder einem Desktop-Rechner anschaust, überall wird der Inhalt optimal lesbar dargestellt.
Dein eigener Geschmack ist ein schlechter Ratgeber in der Frage der Beurteilung, ob ein Design nun gut oder schlecht ist. Lass uns da mal objektiver ran gehen.
Seit fast zwei Jahren besitze ich einen Amazon Echo. Das Gerät zeigt mir seitdem eindrucksvoll, wie limitiert heutzutage Sprach-Interfaces sind. Da muss sich was tun. Amazon hat das schon erkannt und statt einer Verbesserung des Sprachinterfaces zwei Echo-Geräte mit Bildschirm ins Rennen geschickt.
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.
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.
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 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.
0 Antworten
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.
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.
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 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.