Quelltext erklären

[neelix]

Hallo zusammen,

es geht nicht um eine mit Contao erstellte Seite. Ich versuche nur den Quelltext zu verstehen um beutreilen zu können, ob der das erzeugt was er soll.

Das Ziel war: Es sollen für unterschiedliche Endgeräte die passenden Bilder (Größe, Datenmenge) ausgespielt werden, sodass sich (durch geringe Dateigrößen) auch die Ladezeit der Seite verbessert. Der Inhalt des Bildes ist immer gleich, also kein "wichtiger Teil". So der Auftrag an die Agentur. Und es sollte "lazy-loading" genutzt werden.

Herausgekommen ist im Quellext folgendes:

<picture>
   <source data-variant="default" data-maxwidth="1100" media="(min-width: 1200px)" srcset="/fileadmin/images/news/2023_News/Azubifoto_600x397.jpg 1x">
   <source data-variant="large" data-maxwidth="920" media="(min-width: 992px)" srcset="/fileadmin/images/news/2023_News/Azubifoto_600x397.jpg 1x">
   <source data-variant="medium" data-maxwidth="680" media="(min-width: 768px)" srcset="/fileadmin/images/news/2023_News/Azubifoto_600x397.jpg 1x">
   <source data-variant="small" data-maxwidth="500" media="(min-width: 576px)" srcset="/fileadmin/_processed_/0/4/csm_Azubifoto_600x397_22b8fc58df.jpg 1x">
   <source data-variant="extrasmall" data-maxwidth="374" srcset="/fileadmin/_processed_/0/4/csm_Azubifoto_600x397_0f116af9bf.jpg 1x">
   <img loading="lazy" alt="12 Auszubildende starten in ihr erstes Jahr" src="/fileadmin/images/news/2023_News/Azubifoto_600x397.jpg" width="600" height="397">
</picture>

Und irgendwie habe ich den Eindruck, dass das nicht das von uns gewünschte ist. Erwartet hätte ich ein <img srcset> Element und kein <picture>. Es sollten ja keine unterschiedlichen Bilder ausgespielt werden, sondern ein und dasselbe Bild in angepasster Größe.

Habe ich einen Denkfehler oder die Agentur?

Danke & Gruß

Neelix

[lbableck]

Habe ich einen Denkfehler oder die Agentur?

Weder noch würde ich sagen
Beide Möglichkeiten können für sowas verwendet werden, img srcset wäre zwar wahrscheinlich sinnvoller, aber mit picture geht das genauso.

[neelix]

Irgendwie habe ich aber den Eindruck, dass es nicht tut, was es soll.
Ich schicke dir mal einen Link als PM. Ruf die Seite und dann eine News mal auf einem Mobiltelefon auf.

[Spooky]

Und irgendwie habe ich den Eindruck, dass das nicht das von uns gewünschte ist. Erwartet hätte ich ein <img srcset> Element und kein <picture>. Es sollten ja keine unterschiedlichen Bilder ausgespielt werden, sondern ein und dasselbe Bild in angepasster Größe.

Laut deiner Aussage willst du unterschiedliche Bilder haben (die Unterscheidung liegt in der Größe).

[neelix]

Ja, jein.

Primär unterschiedliche Auflösungen (und damit auch Dateigrößen) für unterschiedliche Pixeldichten und Bildschirmauflösungen.

Dann mal doch die Seite:
https://www.rvk.de/pressemitteilungen

Und als Beispiel hier mal die News "04.09.2023 Grenzenlose Mobilität" aufrufen. (PC und Smartphone)

Wie auch immer. Die Agentur muss da nochmal ran. Denn so haben sie die ganze Darstellung zerschossen.

Ich hätte jetzt soetwas als Ergebnis erwartet: https://youtu.be/ub8yROSQyQ4?t=1120

[lbableck]

Prinzipiell funktioniert das denke ich schon richtig und mit ein bisschen CSS wird das Bild auch nicht größer angezeigt als es soll.
Bildschirmfoto 2023-09-21 um 15.24.47.png

[lucina]

Gib der Bildgrösse mal als CSS-Klasse img-fluid mit, dann passt das schon.

[neelix]

Mal schauen, was die morgen sagen. Darf sich unsere Konzernkommunikation drum kümmern.

Aber wenn ich den Vortrag von Peter Müller aus 2016 richtig verstehe, dann ist <picture> doch eigentlich zuviel des Guten.
Ein <img srcset> sollte für den Zweck ausreichen, dass aus einem Bild mehrere für unterschiedliche Auflösungen und Dixeldichten werden, oder?
Die sind ja jetzt, dadurch, dass hinter den Bildern überall "1x" steht, gar nicht bedacht.

Das Ziel ist ja, dass insb. auf mobilen Endgeräten Dateien mit geringeren Auflösungen (und dadurch auch geringerer Dateigröße) geladen werden können, was den Seitenaufbau beschleunigt.

[lbableck]

Ein <img srcset> sollte für den Zweck ausreichen, dass aus einem Bild mehrere für unterschiedliche Auflösungen und Dixeldichten werden, oder?

Das stimmt, ja, img srcset reicht dafür auch.

[neelix]

Gib der Bildgrösse mal als CSS-Klasse img-fluid mit, dann passt das schon.

Ich mache da gar nichts. Mein Auftrag für die Kolleginnen ist gerade nur herauszufinden, ob die Agentur die Aufgabenstellung richtig umgesetzt hat.

Und da ich eigentlich etwas anderes erwartet hatte, war/bin ich mir da nicht so sicher. Zumal die Darstellung ggü. vorher (traditionell) jetzt nicht mehr funktioniert. Da müssen sie also morgen nochmal ran. Wie sie das lösen ist mir egal.

[lucina]

¯\_(?)_/¯

[neelix]

Ich komme noch nichtmal an die Dateien ran aus denen das CSS generiert wird. Im Backend kommen wir nur an die Inhalte ran, die wir selbst pflegen müssen. Den Rest erledigt die Agentur.
Auf die TypoScript-Dateien und was sonst noch zum Template gehört, haben wir keinen Zugriff.

Ich sollte nur schauen, ob der Auftrag richtig ausgeführt wurde.

Bis auf die Tatsache, dass die Darstellung nicht mehr stimmt, habe ich mitgenommen: Man kann das mit <picture> lösen, aber vollständig ist die Lösung aus meiner Sicht nicht.

Zum eine verweise alle <source> Element auf ein und die selbe Datei (s.o.), was ja keinen Sinn macht. Das könnte ab dem geschuldet sein, dass Typo3 die Dateien nur beim ersten Upload erstellt und die Kolleginnen jetzt alle Newsbilder einmal neu hochladen und einbinden müssten, oder der _processed-Ordner geleert werden muss. Das müssen wir morgen mal erfragen, bevor wir den Fehler der Agentur um die Ohren hauen.

[lbableck]

Zum eine verweise alle Element auf ein und die selbe Datei (s.o.), was ja keinen Sinn macht.

Bei dem o. g. Beitrag „Grenzenlose Mobilität“ werden schon unterschiedliche Bilder in den source Elementen ausgespielt, zumindest das scheint also zu passen.

[neelix]

Ja, ich habe eine Möglichkeit gefunden, wie ich den Ordner leeren kann und - no risk, no fun - die gut 12.000 Objekt mal gelöscht. Jetzt muss ich mich nur einmal durch die Seite klicken, damit Typo3 die Bilder wieder generiert.

Aber sauber scheint das nicht zu sein. Denn nur wenn ich die Seite auf dem PC aufrufe generiert er die Bilder. Auf dem Smartphone sah ich nur kaputte Elemente. Erst nach dem Aufruf auf dem PC waren sie auf dem Smartphone auch wieder da. Das zeigt mir, dass PC und Smartphone die gleichen Bilder laden.

[mineralwa]

... Contao, nicht Typo3 ...? Aber ein Lob hier in der Community, dass auch andere Systeme supportet werden ;-)

[Spooky]

... Contao, nicht Typo3 ...

Es geht hier nicht um eine Contao Seite (zumindest laut dem initialen Post).

[mineralwa]

Es geht hier nicht um eine Contao Seite (zumindest laut dem initialen Post).

Habs gerade gesehen.

[neelix]

Ja, diese Seite wurde mit Typo3 erstellt. Deswegen auch unter Off-Topic. Mir ging es aber die HTML Umsetzung

[zoglo]

Ja, diese Seite wurde mit Typo3 erstellt. Deswegen auch unter Off-Topic. Mir ging es aber die HTML Umsetzung

Die Variante, welche du erwartet hast (https://youtu.be/ub8yROSQyQ4?t=1120), funktioniert nicht zuverlässig auf Safari (Seit 2015):
- https://bugs.webkit.org/show_bug.cgi?id=149899

Das Verwenden von <picture> ist valide, hier gibt es also keinen Denkfehler.
Auch Contao erstellt es mit <picture> und <source> und nicht in der von dir erwarteten Variante.

MfG

[neelix]

Der Bug betrifft das Verhalten von Safari, dass er bei einer Größenänderung des Fensters ggü. z.B. Chrome nicht automatisch das Bild austauscht.
Nicht aber, dass er es gar nicht erst lädt.

Contao erstellt, das was ich ihm sage. Wenn ich keine unterschiedlichen Media Queries definiere, dann bekomme ich auch keine. Dann regeln pures HTML und CSS die Anzeigegröße, aber der Browser sucht sich aus dem Srcset die passende Datei für eine optimale Darstellung.

Mit dem kleinen Unterschied, dass bei srcset mit w-Werten auch die Pixeldichte berücksichtigt ist. Und das fehlt mir bei dem Beispiel oben. Da sind zwar (inzwischen unterschiedliche) Dateien für die einzelnen Breakpoints definiert, aber ein iPhone mit DPR=3 bekommt so eine kleinere Grafik, die es dann wieder auf die gewünschte Größe aufzieht. Unschärfe inklusive.

Zumindest hätte ich erwartet, dass es Dateien für 1x, 2x und 3x gibt.

[neelix]

So, die Agentur hat jetzt nachgebessert. Die Bildgrößen auf den Detailseiten stimmen wieder.

Sie meinen die DPR müsste man nicht berücksichtigen, wenn man die Bilder alle mit 150dpi erstellt (statt der im Web üblichen 72dpi). Dann wären die auch auf Retina-Displays scharf.
Stimmt das so? Was meinen die Grafiker unter euch?

[Spooky]

Ich denke die Agentur hat nicht verstanden, wie Bilder im Web funktionieren. Die "dpi" aus dem Druck sind völlig irrelevant (mehr oder weniger... wenn die Agentur damit aussagt, dass die Bilder am besten in doppelter Auflösung dem System zur Verfügung stehen sollen, dann ist das natürlich nicht ganz falsch).

Angenommen du willst ein 100 mal 100 Pixel (= "CSS Pixel") großes Bild darstellen. Auf einem Ausgabegerät mit einem dppx Wert von "1" (1 CSS Pixel entspricht einem pysischen Pixel auf dem Ausgabegerät) muss das Bild in einer Auflösung von 100 mal 100 Pixel vorliegen. Auf einem Ausgabegerät mit einem dppx Wert von "2" ("Retina", 1 CSS Pixel entsprechen zwei mal zwei physischen Pixel auf dem Ausgabegerät) muss das Bild in einer Auflösung von 200 mal 200 Pixel vorliegen. Auf einem Ausgabegerät mit einem dppx Wert von "3" (Samsung Galaxy S4, S5, etc.) muss das Bild in einer Auflösung von 300 mal 300 Pixel vorliegen, usw. damit das Bild immer gestochen scharf aussieht - also damit ein Pixel des Bildes immer genau einem physischen Pixel des Ausgabegeräts entspricht.

Also:

<img src="100x100.jpg" width="100" height="100" srcset="200x200.jpg 2x, 300x300.jpg 3x">

Es gibt in der Wildnis auch dppx Werte, die nicht ganzzahlig sind. Samsung Galaxy S2 bspw. mit einem dppx Wert von 1.5x. Und unter Windows sind Desktop/Laptop Geräte mit einer eingestellten Zoom Stufe von 125% (= dppx 1.25) oder 150% (= dppx 1.5) sehr üblich. Es macht aber vermutlich wenig Sinn für jede erdenkliche Variante auch die entsprechende Pixeldichte zur Verfügung zu stellen. Auf einem Gerät mit dppx@1.25 nimmt der Browser dann z.B. das 2x Bild und rechnet es runter (und nicht umgekehrt, vorausgesetzt man hat die sizes korrekt definiert).

[neelix]

Ja, was meinst Du, warum ich so darauf rumreite, dass die <source> Elemente kein srcset enthalten.

Der Browser hat zwar für unterschiedliche Displaybreiten Dateien zur Auswahl. Auf dieser Ebene aber dann keine Wahl mehr für höhere Pixeldichten.

Laut mydevice.io hat mein Sony Xperia 10 III einen dppx Wert von 2.61 und einen Viewport von 414px (x960px). Ich bräuchte hier also ein Bild mit der dreifachen Pixelanzahl der eigentlichen darzustellenden Pixel.

Die Werte habe ich jetzt mal im Edge/Chrome eingetragen und geschaut welches Bild er lädt.

Das Bild soll 372px breit sein und die Datei, die sowohl Edge auf dem PC als auch der Firefox auf meinem Smartphone auswählen ist 374 Pixel breit. Soweit passt das also schon mal.
Aber wenn ich die Grafiken auf dem PC vergleiche, dann dürfte die Smartphone Version gerne etwas schärfen sein, oder?
Schalte ich auf dem Smartphone die Seite nämlich in den Desktop-Modus, dann bekomme ich eine schärfere Darstellung, weil er jetzt das Bild für 500px Breite lädt.

Die Agentur hat unseren Mädels folgenden Workflow für die Bilder empfohlen:
- Das Bild in Photoshop in der gewünschten Größe und 150dpi anlegen (für die News i.d.R. 600x irgendwas)
- Das Bild "für Web speichern"
- Das Bild bei TinyPNG hochladen um die Größe zu reduzieren
- Das Bild im Typo3 hochladen und einbinden
- Typo3 erzeugt dann die nötigen Auflösungen/Bildgrößen

Bisher sind die Mädels immer mit 300dpi unterwegs gewesen. Die kommen meines Wissen alle aus der Print-Welt und das meiste, was die bei uns erstellen wird später im Format A2 geduckt. Web haben die nie gelernt. Das geben sie auch offen zu und verlassen sich hier auf die Aussagen der Agentur. Von der Technik dahinter haben die Null Ahnung.

Also sollte ich der Agentur am Montag wohl erklären, dass die DPR sehr wohl eine Rolle spielt.