<picture>-Tag wird Web-Nutzung bald deutlich beschleunigen

Ein neues HTML-Tag soll die Nutzung des Webs vor allem auf mobilen Endgeräten demnächst deutlich beschleunigen. Nach mehreren Jahren der Vorbereitung wird dieses bald von den ersten Browsern unterstützt und soll einen neuen Weg im Umgang mit Bildern ... mehr... Web, Code, Html Bildquelle: Ashish Lala Web, Code, Html Web, Code, Html Ashish Lala

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Das ist eine gute Sache. Bislang hat das mit Adaptive Images serverseitig geklappt, aber warum soll der Client nicht selbst entscheiden, welche Größe er braucht? Oh nein, den letzten Satzteil nicht falsch verstehen!
 
Ist dieses Tag (ernst gemeinte Frage) ein proprietärer Google-Tag, dem die anderen Browserhersteller hinterher rennen (müssen), oder ist das ein offizieller Standard?

Die Aussage "Nach einigen Diskussionen und Auseinandersetzungen mit den Standardisierungsbehörden" deutet ja eher auf ersteres?

edit: Unabhängig davon betrachte ich dieses Tag natürlich als sinnvoll.
 
@rallef: Standard ist es noch nicht, falls es sowas überhaupt gibt im Web. Selbst das W3C redet meistens nur von Empfehlungen. Momentan findet sich das picture-Element im HTML 5.1 Nightly Entwurf: http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#the-picture-element
 
@rallef: offizieller Standard ist derzeit weder html5 noch css3. Aber das Picture Element ist vom W3C vorgesehen:
http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#the-picture-element
 
Klingt gut. Vor allem im Edge-Netz oder wenn man wiedermal gedrosselt wird dürfte das zu einer deutlich schnelleren Ladezeit beitragen.
 
@Memfis: Ich bin letzte Woche zufällig mit dem Auto durch Österreich gefahren und hab im Autoradio eine Werbung über einen bezahlbaren Datentarif ohne Drosselung gehört. Ich bin schwer beeindruckt. Ich gehe nicht davon aus, dass eine Datenreduzierung auf Grund technischer Hintergründe nötig ist. Trotzdem begrüße ich diese Entwicklung für uns gegängelte Deutsche. :)
 
@shinguin: Österreich ist aufgrund der "größe" oft Testland für Mobil-Tarife. Mir stellt es immer die Nackenhaare auf wenn ich Tarife aus Deutschland sehe ^^
 
@wischi: Dann solltest Du Dir mal die Schweizer Mobiltarife ansehen. DAS ist schockierend.
 
@iamthief79: So teuer oder so günstig? :) (ernst gemeint)
 
@wertzuiop123: So teuer ;)
 
im img tag wird aber nur eine Bildquelle angegeben... verstehe gerade nicht wie das interagiert.
 
@knirps: So wie ich es da oben rauslese, wird die Bildquelle im IMG Tag als eine Art ID für den Source Tag genutzt. Und da IMG ein Child von Picture ist, wählt der Browser, der den Picture Tag kennt, je nach User-Agent oder Auflösung die entsprechende Quelle...

und ich denke es wird keine "richtige" ID genutzt, um Browser, die nix mit dem Picture Tag anfangen können, trotzdem ein Bild anzeigen zu lassen, dann allerdings ohne variable Bildgröße

(Hoffe du verstehst wie ichs meine)
 
@Slurp: Ja, ich denke ich verstehe wie du das meinst.
@dodnet: War auch mein erster Gedanke, eine wirklich saubere Lösung ist das nicht.
 
@knirps: Ich denke das img-Tag ist in der alten Form, damit es abwärtskompatibel bleibt. Vermutlich greift die neue Routine dann automatisch auf das <source>-Tag innerhalb des <picture>-Tags zu. Sprich, die müssen immer in dieser Dreierkombination auftreten.

Finde ich aber etwas umständlich gelöst, hätte man hier nicht einfach ein zusätzliches Attribut einführen können, so in der Art:
<img src="1.jpg" alt="..." altsize="2.jpg, 3.jpg">
 
@dodnet: Ein Attribut, wie Du es vorschlägst, ist nicht die Lösung. Du kannst dem Picture-Tag bei <SOURCE> nämlich eindeutig sagen, unter welchen Bedingungen welches Bild genutzt wird (Auflösung, verfügbare Breite des Viewports...).

Und mir persönlich ist das scheinbar Komplizierte deutlich lieber als ein unübersichtlicher <IMG>-Tag mit gefühlt 2000 Attributen. Mein Code neigt ohnehin schon immer dazu, chaotisch zu wirken. Der <PICTURE>-Tag bringt mehr Struktur in den Quelltext.
 
Mir ist gerade das Artikelbild aufgefallen. Das HTML da drin ist aber nicht gerade.. ähm, korrekt. Verfolgt die Auswahl des Bildes einen bestimmten Zweck?
 
@psylence: Einfach Symbolbild... Dass das nich korrekt ist, weiß man denke ich.
 
@psylence: hehe, voll korrekt ist das ;)
 
Kann mir wer verraten warum wir da eine XML Abart haben, wenn wir dann erst wieder alles in einen String packen und den dann parsen müssen? srcset="cover1x.jpg 1x, cover2x.jpg 2x, cover4x.jpg 4x" ist doch doof. Wäre nicht src1="cover1.jpg" src2=cover2.jpg" viel eleganter da man die einzelnen Attribute direkt ansprechen könnte ohne den langen string am Komma zu parsen?
 
@Sam Fisher: Das ganze ist doch relativ analog zum video-tag ? src1, src2 ist jetzt auch nicht viel eleganter... Neben dem Bild musst du auch noch eine Bedingung angeben können

<img src="cover1.jpg" src1="cover1.jpg" src1con="1x" src2="cover2.jpg" src2con="2x" />

Finde ich deutlich unschöner ;)
 
Der Source-Tag ist in gleicher Methode auch bereits für Audio/Video-Tags vorhanden, deshalb hat man das wohl zwecks Einheitlichkeit übernommen.

Der Source-Tag umfasst aber nicht nur die einzelnen Bild-Pfade, sondern kann auch auch die Bedingungen dazu bestimmen. Im oberen Beispiel werden nach jedem Bild mit 1x, 2x, 3x... verschiedene Pixel Density-Varianten angesprochen (für Mobile-Varianten relevant). Wahlweise kannst du auch direkte Mindest-Pixel-Breitenangaben definieren also zB "1024w" oder "1650w".

Die Bedingungen kann man aber auch abkapseln und in ein extra "sizes"-Attribute stecken.

Was der Artikel hier aber nicht wiedergibt: Der Picture-Tag ist im Prinzip nur bei mehreren Sources mit bestimmten media-Conditions notwendig. Man kann also mehrere source-Tags in den Picture-Tag packen und gezielt Bildergruppen zb mit media="(min-width: 1650px)" / media="(max-width: 800px)" für ganz bestimmte Auflösungen definieren.

Hat man nur eine einzelne Liste kann man den srcset-Tag nämlich auch direkt ins img-Tag packen und auf den picture-Tag getrost verzichten.

Hier nochmal mit visuellen Beispiel: http://responsiveimages.org/
 
Wünsche ich mir seit Jahren. Jetzt muss ein Bild bei Zoomfaktor nicht mehr verwaschen aussehen. Top!
 
@Matti-Koopa: Viel besser: Ich muss nicht das dicke, fette HiRes-Bild laden und Unmengen an Daten transferieren, wenn ich die Seite auf dem Smartphone aufrufen und optisch nicht viel davon habe, weil das Display so klein ist.
 
@Der Lord: normalerweise sollte man, nach dem mobile first gedanken, als default bild das mit der kleinsten auflösung laden und dann bei bedarf größer nachladen
 
@tehace: Genau das kannst Du, wenn ich das Konzept richtig verstehe, mit dem <PICTURE>-Tag realisieren. Unter anderem. Wirf mal einen Blick in den Link zu dem Tag oben im Text.
 
@Der Lord: ich hab keine frage gestellt, sondern ne aussage getätigt und nutze das auch so :D im oberen beispiel wird auch das kleinste bild als fallback geladen :)
 
@tehace: Nicht ganz. Der <IMG>-Tag dient AUCH als Fallback, das ist richtig. Der Trick ist, dass der Browser abhängig von den im <SOURCE>-Tag deklarierten Konditionen unterschiedliche Bilder anfordert. Diese Konditionen kann man - soweit ich es verstehe - so definieren, dass auf dem mobilen Gerät eben das kleine Bild abgerufen wird. Geht über das media-Attribut. Dein Desktop, der an einem 200-Zoll-4k-TV hängt, lädt dann das große, dicke HiRes-Bild.

<PICTURE> und <SOURCE> laden noch kein Bild. Das macht <IMG>. Man gibt dort das kleinste Bild an, ob es aber tatsächlich geladen wird, hängt von den Deklarationen im media- und im srcset-Attribut ab. Es wird in jedem Fall nur EIN Bild geladen - zweckdienlicherweise das kleinste Bild. Ich vermute mal, dass man das <IMG> wie bisher auch zusätzlich noch in ein <A></A> verpacken und so ggf. ein HiRes-Bild auf Anforderung nachladen kann. Ich denke, das ist es, worauf Du hinaus willst, oder? :)
 
Ein Bild als SVG aufzulösen schlägt diese Lösung halt um Längen und ist dann tatsächlich auch -NATIV- (ohne Zusatzattribute) Bildgrößen unabhängig. Eben nicht diese quasi-Lösung.
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte