Problem mit Bildgrößen bei responsive Ausgabe (seit Kurzem)

[Kahmoon]

Hallo zusammen,

heute ist mir aufgefallen das in der mobilen Ansicht einer Seite von uns die Bilder nicht mehr auf die ganze Spalte gehen (Ansicht iPhone.jpg). Das lief aber 100% schon mal. Egal was ich einstelle.....irgendwie bekomme ich es nicht mehr füllend für die Spalte.

Das Komische an der Sache ist...am Browser mit der responsive Vorschau der Entwicklertools passt es (Ansicht Entwicklertools). Auf 2 iPhones (11 & 12) nicht. Und nur wenn ich die Grundeinstellungen der Bilder größer einstelle als es im Desktopformat ausgegeben wird, passt es auch mobile. Aber das sollte so ja ned sein.

Hat sich hier irgendwas in den letzten Core Updates geändert? Ich hab beim gestrigen Updates mal eine Zeile für Images gesehen....hab das aber nicht weiter beachtet.



Anbei Screenshots

VG

[Kahmoon]

Wichtig: Desktop hat immer kleinere Versionen als die mobile Versionen. Es wirkt so als würde er bei den Kindeinstellungen für bestimmte Größen eine größere Angabe als im Hauptelement ignorieren. Höhe hingegen verändert sich wenn ich etwas anpasse.

Stelle ich für das Hauptelement 480px Breite ein, passt es auch für mobile. Ich brauche am Desktop dieses Element aber nur mit 218px

Nur mal zum Verständnis:
Ich definiere bisher die Grundgrößen immer auf Desktop und erstelle dann für kleine Auflösungen entsprechend weitere Einstellungen. Das ist doch korrekt oder nicht? Bisher hat das immer geklappt. Erst seit dem gestrigen Update auf die neuste Version ist das jetzt scheintbar "zerschossen".

[mlweb]

Insgesamt muss man immer zwei Dinge unterscheiden. In welcher Größe soll das Bild für die einzelznen Viewports dargestellt. Das ist CSS meist zusammen mit media-queries.
der zweite Bereich sind die responsiven Bilder - welche Bildgröße stelle ich für welchen Viewport zur Verfügung.
Insgesamt hat sich da m.E. nichts verändert in letzter Zeit.

Nachtrag: ok so frisch (gestern) ist mein Update nicht.

[Kahmoon]

Ich habe eine Zeile beim Update gesehen. Kann es aber nicht mehr nachschauen.

Die Funktionsweise ist mir eigentlich klar (hatte ich ja auch in den Screenshots oben gezeigt) und es ging auf der Seite auch schon. Das wäre uns vorher schon aufgefallen. Wie oben geschrieben ignoriert er die Bildbreite im Kindelement wenn diese größer ist als die Einstellung im Hauptelement.

Also:

• Bildgröße Hauptelement XY 350x120
  
  • max-width 480: 480x150 (geht nicht - Breite bleibt 350, Höhe verändert sich)
  • max-width 480: 100x150 (geht nicht - Breite bleibt 350, Höhe verändert sich)

Bin mir ziemlich sicher dass das ein Bug ist...hmmmm

[mlweb]

Bei mir würden allerdings die Bildgröße anders aussehen.

Unten bei Sizes-Attribut hätte ich z.B. stehen:

(max-width:600px) 100vw, 218px

wenn ich bis zu einem Viewport von 600px möchte, dass eine Bild ca. 100% des Viewports ausfüllt und für alle Geräte die einen größeren Viewport haben, dann die 218px.

Bei den Bildgrößen gehe ich in dem Fall meist auf die Angabe in w, weil das für mich anschaulicher ist. Da würde ich wohl ein paar Größen mehr einstellen.

Zusätzliche Queries bei den einzelnen Bildgrößen habe ich bisher noch nie genutzt.

[Kahmoon]

Aber muss man das nicht mit Kindelementen machen? Ich will ja bei den Bootstrap Breakpoints die Bilder anpassen. Die Formate ändern sich ja je nach Auflösung auch von der Proportion her. Aber vielleicht habe ich da auch einen Denkfehler

[mlweb]

Übrigens ich kann in den Entwicklertools des Browsers (Firefox) Dein ungewünschtes Phänomen sehen.

[Kahmoon]

Ja, total seltsam warum das auf einmal so ist... (Chrome Entwicklertools bei mir)

Ich muss jetzt alle 20 Bildeinstellungen umbauen :-(. Sprich Elternelement keine Größe geben und nur in den Kindelementen Einstellungen vornehmen und extra für Desktop eine Auflösung hinzufügen.

[mlweb]

Aber muss man das nicht mit Kindelementen machen? Ich will ja bei den Bootstrap Breakpoints die Bilder anpassen. Die Formate ändern sich ja je nach Auflösung auch von der Proportion her. Aber vielleicht habe ich da auch einen Denkfehler

Das kann ich Dir leider nicht genau sagen. Ich arbeite nicht mit Bootstrap, aber wenn sich die Proportionen ändern sollen, ist das nach meinem Verständnis durchaus ein Einsatz für die Kindelemente. Habe ich so noch nicht gebraucht/eingesetzt.

Ich würde dafür einen Testcase aufsetzen glaube ich.

[Kahmoon]

Mit Bootstrap selbst hat das nicht direkt zu tun. Nur Core responsive Images. Aber das Layout verändert sich halt bei den Bootstrap Breakpoints. Sprich ab dann muss/möchte ich auch mit den Bildgrößen über den Core reagieren.

Ich schau mal ob ich ne Testseite bauen kann.

[Kahmoon]

Also hier ist die Testseite. Leider funzt gar nichts mehr so wie vorher.

Entwickler Chrome zeigt alles an wie es sein soll.
Entwickler Firefox und leider auch aktuelle Smartphones hingegen funktionieren nicht. Bild ist auch super unscharf obwohl es in x fach besserer Auflösung vorliegt.

Siehe Anhänge



Und hier noch das Updatelog von gestern (roter Bereich habe ich in Verdacht):

[7.8MiB/0.18s] Loading composer repositories with package information
[72.9MiB/1.87s] Updating dependencies
[147.7MiB/22.20s] Lock file operations: 1 install, 66 updates, 0 removals
[147.7MiB/22.20s]   - Upgrading codefog/contao-events_subscriptions (2.10.7 => 2.12.2)
[147.7MiB/22.20s]   - Upgrading composer/ca-bundle (1.2.9 => 1.2.10)
[147.7MiB/22.21s]   - Upgrading contao/conflicts (dev-main 0b4a4dc => dev-main 1b5cc17)
[147.7MiB/22.21s]   - Upgrading doctrine/doctrine-bundle (2.3.2 => 2.4.2)
[147.7MiB/22.21s]   - Upgrading doctrine/orm (2.9.1 => 2.9.2)
[147.7MiB/22.22s]   - Upgrading heimrichhannot/contao-utils-bundle (2.192.1 => 2.193.0)
[147.7MiB/22.22s]   - Upgrading knplabs/knp-menu (v3.1.3 => v3.2.0)
[147.7MiB/22.22s]   - Upgrading madeyourday/contao-rocksolid-frontend-helper (v2.0.11 => v2.0.12)
[147.7MiB/22.22s]   - Upgrading markbaker/complex (2.0.2 => 2.0.3)
[147.7MiB/22.23s]   - Upgrading markbaker/matrix (2.1.2 => 2.1.3)
[147.7MiB/22.23s]   - Upgrading php-http/discovery (1.13.0 => 1.14.0)
[147.7MiB/22.23s]   - Upgrading phpoffice/phpspreadsheet (1.17.1 => 1.18.0)
[147.7MiB/22.24s]   - Upgrading scheb/2fa-backup-code (v5.9.0 => v5.10.0)
[147.7MiB/22.24s]   - Upgrading scheb/2fa-bundle (v5.9.0 => v5.10.0)
[147.7MiB/22.24s]   - Upgrading scheb/2fa-trusted-device (v5.9.0 => v5.10.0)
[147.7MiB/22.24s]   - Upgrading symfony/asset (v5.2.7 => v5.2.10)
[147.7MiB/22.25s]   - Upgrading symfony/cache (v5.2.9 => v5.2.10)
[147.7MiB/22.25s]   - Upgrading symfony/config (v4.4.23 => v4.4.25)
[147.7MiB/22.25s]   - Upgrading symfony/console (v4.4.24 => v4.4.25)
[147.7MiB/22.26s]   - Upgrading symfony/css-selector (v5.2.9 => v5.3.0)
[147.7MiB/22.26s]   - Upgrading symfony/debug (v4.4.22 => v4.4.25)
[147.7MiB/22.26s]   - Upgrading symfony/dependency-injection (v4.4.24 => v4.4.25)
[147.7MiB/22.26s]   - Upgrading symfony/doctrine-bridge (v4.4.24 => v4.4.25)
[147.7MiB/22.26s]   - Upgrading symfony/dom-crawler (v4.4.24 => v4.4.25)
[147.7MiB/22.27s]   - Upgrading symfony/dotenv (v5.2.4 => v5.2.10)
[147.7MiB/22.27s]   - Upgrading symfony/error-handler (v4.4.23 => v4.4.25)
[147.7MiB/22.27s]   - Upgrading symfony/event-dispatcher (v4.4.20 => v4.4.25)
[147.7MiB/22.27s]   - Upgrading symfony/expression-language (v5.2.7 => v5.2.10)
[147.7MiB/22.27s]   - Upgrading symfony/filesystem (v5.2.7 => v5.2.10)
[147.7MiB/22.28s]   - Upgrading symfony/finder (v5.2.9 => v5.2.10)
[147.7MiB/22.28s]   - Upgrading symfony/framework-bundle (v4.4.24 => v4.4.25)
[147.7MiB/22.28s]   - Upgrading symfony/http-client (v5.2.9 => v5.2.10)
[147.7MiB/22.28s]   - Upgrading symfony/http-foundation (v4.4.23 => v4.4.25)
[147.7MiB/22.28s]   - Upgrading symfony/http-kernel (v4.4.24 => v4.4.25)
[147.7MiB/22.28s]   - Upgrading symfony/lock (v5.2.8 => v5.2.10)
[147.7MiB/22.29s]   - Upgrading symfony/mailer (v5.2.7 => v5.2.10)
[147.7MiB/22.29s]   - Upgrading symfony/mime (v5.2.9 => v5.3.0)
[147.7MiB/22.29s]   - Upgrading symfony/monolog-bridge (v5.2.7 => v5.2.10)
[147.7MiB/22.29s]   - Upgrading symfony/options-resolver (v5.2.4 => v5.3.0)
[147.7MiB/22.29s]   - Upgrading symfony/polyfill-ctype (v1.22.1 => v1.23.0)
[147.7MiB/22.29s]   - Upgrading symfony/polyfill-intl-grapheme (v1.22.1 => v1.23.0)
[147.7MiB/22.30s]   - Upgrading symfony/polyfill-intl-idn (v1.22.1 => v1.23.0)
[147.7MiB/22.30s]   - Upgrading symfony/polyfill-intl-normalizer (v1.22.1 => v1.23.0)
[147.7MiB/22.30s]   - Upgrading symfony/polyfill-mbstring (v1.22.1 => v1.23.0)
[147.7MiB/22.30s]   - Upgrading symfony/polyfill-php72 (v1.22.1 => v1.23.0)
[147.7MiB/22.30s]   - Upgrading symfony/polyfill-php73 (v1.22.1 => v1.23.0)
[147.7MiB/22.30s]   - Upgrading symfony/polyfill-php80 (v1.22.1 => v1.23.0)
[147.7MiB/22.31s]   - Locking symfony/polyfill-php81 (v1.23.0)
[147.7MiB/22.31s]   - Upgrading symfony/process (v5.2.7 => v5.2.10)
[147.7MiB/22.31s]   - Upgrading symfony/property-access (v5.2.4 => v5.3.0)
[147.7MiB/22.31s]   - Upgrading symfony/property-info (v5.2.8 => v5.3.1)
[147.7MiB/22.31s]   - Upgrading symfony/routing (v4.4.24 => v4.4.25)
[147.7MiB/22.31s]   - Upgrading symfony/security-bundle (v4.4.23 => v4.4.25)
[147.7MiB/22.32s]   - Upgrading symfony/security-core (v4.4.24 => v4.4.25)
[147.7MiB/22.32s]   - Upgrading symfony/security-csrf (v5.2.7 => v5.2.10)
[147.7MiB/22.32s]   - Upgrading symfony/security-guard (v4.4.23 => v4.4.25)
[147.7MiB/22.32s]   - Upgrading symfony/security-http (v4.4.24 => v4.4.25)
[147.7MiB/22.32s]   - Upgrading symfony/stopwatch (v5.2.7 => v5.2.10)
[147.7MiB/22.32s]   - Upgrading symfony/string (v5.2.8 => v5.3.0)
[147.7MiB/22.32s]   - Upgrading symfony/templating (v5.2.4 => v5.3.0)
[147.7MiB/22.33s]   - Upgrading symfony/translation (v4.4.24 => v4.4.25)
[147.7MiB/22.33s]   - Upgrading symfony/twig-bridge (v4.4.22 => v4.4.25)
[147.7MiB/22.33s]   - Upgrading symfony/twig-bundle (v4.4.24 => v4.4.25)
[147.7MiB/22.33s]   - Upgrading symfony/var-dumper (v5.2.8 => v5.2.10)
[147.7MiB/22.33s]   - Upgrading symfony/var-exporter (v5.2.8 => v5.3.0)
[147.7MiB/22.33s]   - Upgrading symfony/web-profiler-bundle (v4.4.23 => v4.4.25)
[147.7MiB/22.34s]   - Upgrading symfony/yaml (v5.2.9 => v5.2.10)
[146.9MiB/22.35s] Writing lock file
[83.1MiB/22.41s] <warning>Package league/uri-hostname-parser is abandoned, you should avoid using it. No replacement was suggested.</warning>
[83.1MiB/22.41s] <warning>Package league/uri-schemes is abandoned, you should avoid using it. No replacement was suggested.</warning>
[83.1MiB/22.42s] <warning>Package patchwork/utf8 is abandoned, you should avoid using it. Use symfony/polyfill-mbstring or symfony/string instead.</warning>
[83.7MiB/22.43s] Memory usage: 83.68MB (peak: 1506.99MB), time: 22.45s.
[83.7MiB/22.44s] Finished Composer Cloud resolving.




# Job ID bZuCfm1Cd2dtbNLv9X5DVjC4ipb959yKx80zc4ugOJ8a5Pe12Z29iGP6DGKSOxtxtaUquR completed in 27 seconds
# Memory usage: 83.68MB (peak: 1506.99MB), time: 22.45s.


$ /usr/bin/php7.4-cli -q -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /homepages/46/xxx/htdocs/xxx/web/contao-manager.phar.php composer install --prefer-dist --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader --dry-run




# Process terminated with exit code 0
# Result: OK

[Kahmoon]

Habe es gerade in der Contao Demo versucht. Dort klappt alles noch wie gewohnt auf allen Systemen. Siehe Anhänge. Ist aber noch ein Contao 4.9.x

[Kahmoon]

Sorry das ich hier noch mal schieben muss aber leider verursacht das starke Probleme auf unserer Seite und ich muss eine Lösung finden :-)

Ich habe jetzt noch mal zwei einfache Beispiele gebaut bei denen man sieht das es ned funktioniert wie es sollte.
Auch bei einer anderen 4.11.3 Installation mit identischen Beispielen funktioniert es nur im Chrome Desktop.

Wie komme ich denn auf eine 4.11.2 zurück um zu testen ob es daran lag?


Nachtrag: Ich habe das zweite Beispiel gerade auf eine 4.11.2 gedowngraded und siehe da die Bildfunktion läuft wieder!!! FF + Chrome + Mobile!

[Bennie]

Aber in Deinem ersten Besipiel fehlt doch die CSS Angabe für img

max-width: 100%;
height: auto;

oder täusche ich mich?

[Kahmoon]

Das ändert aber leider nicht das eine neue Grafik im gewünschten Format erzeugt wird (habe es jetzt aber zum Vergleich mal eingefügt). Es wird lediglich aufskaliert und somit unscharf. Im zweiten Beispiel mit der 4.11.2 macht er es wie gewünsch erzeugt zwei scharfe Versionen in den angegebenen Einstellungen und verwendet diese auch bei den angegebenen Breakpoints.

Ich könnte jetzt die erste Seite natürlich auch auf 4.11.2 downgraden aber ich würde gerne die Ursache finden und somit anderen helfen die ein ähnliches Problem bekommen.

[ausi]

Kannst du bitte mal versuchen ob folgender CSS-Code das Problem für dich löst?

:where(source[width][height] ~ img) { 
    width: auto;
    height: auto;
}

[Kahmoon]

Kannst du bitte mal versuchen ob folgender CSS-Code das Problem für dich löst?

:where(source[width][height] ~ img) { 
    width: auto;
    height: auto;
}

Das tut es in der Tat....hmmm

[Bennie]

Nur um Missverständnisse auszuräumen, Deine "Grundeinstellung" ist aber auf jeden Fall größer als die "Kindeinstellungen" ?

[Kahmoon]

Nur um Missverständnisse auszuräumen, Deine "Grundeinstellung" ist aber auf jeden Fall größer als die "Kindeinstellungen" ?

Nein, es ist an ganz vielen Stellen so das die Grundeinstellung kleiner ist als die Childs. Brauche ich am Desktop z.B. 200x200 aber mobile die volle Breite 480x100. Das war bis zu 4.11.2 auch nie ein Problem. Funktioniert auch im zweiten Beispiel auf einer 4.11.2

[Bennie]

Hm ok, ich dachte dass sei Voraussetzung für das korrekte Verhalten, aber ich gebe zu dass ich mich auch immer wieder schwer tue mit diesen Einstellungen.

[Spooky]

Das passiert, weil Contao seit 4.11.3 nun auch die width und height Attribute für <source> ausgeben lässt, um theoretisch Bildgrößen mit verschiedenen Seitenverhältnissen korrekt unterstützen zu können.

[Kahmoon]

Muss ich dann generell die Bildgrößen anders aufbauen oder immer den CSS Code von ausi verwenden bzw. sollte das CSS dann nicht in den Core?

[Spooky]

Die Bildgrößen anders aufbauen musst du nicht. Du musst ggf. das CSS anwenden. Der Contao Core sollte nicht automatisch CSS ausgeben.

[Kahmoon]

Hmm aber woher sollen andere Contao Nutzer denn wissen das sie genau diesen Snipped brauchen damit es korrekt funktioniert? Sie können es zufällig hier im Forum finden aber sollte man dem nicht vorgreifen?