Media-Query vs. Layout für mobile Seiten

Hallo zusammen

Ich habe angefangen, mich mit responsivem Design zu befassen. Einige Zusammenhänge habe ich entdeckt und vieles noch nicht verstanden. Z.B. "Wann steuere ich etwas mit dem Layout für mobile Seiten und wann mit Media-Queries?" Ich bin mal diesen Thread durchgegangen und hier hängen geblieben. Immerhin eine eindeutige Aussage. Kürzlich habe ich erstmal auch ein Tablett beigezogen und das Gefühl, "dass ein Tablet sich nicht als mobiles Gerät outet" habe ich auch.

Für ein paar Kernaussagen und Entscheidungshilfen bin ich dankbar.

Wie du ja bereits mitbekommen haben müsstest, brauchst du das Mobile-Layout nur, wenn du auf Mobiles unterschiedliche Module und Inhalte präsentieren möchtest. Hierbei musst du dich auf das UA-Sniffing von Contao verlassen.

Ich selber benutze das nie und arbeite nur mit media-queries. Auch weil man sich dadurch die ganze Pflege eines zweiten Layouts spart.

Was ich noch nicht richtig getestet haben ist, ob z.B. eine große Hintergrundgrafik, welche ich auf kleinen Viewports nicht anzeigen möchte, durch den media-query background-image:none, auch wirklich nicht geladen wird. Ich gehe aber davon aus. Unsicherer bin ich mir damit, ob ein Element, welches mit CSS auf display:none gesetzt wird geladen wird, oder nicht. Vielleicht weiß ja der ein oder andere noch mehr dazu.

Das Problem mit dem mobilen Layout ist aus meiner Sicht, dass nicht alle Geräte "richtig" erkannt werden, also mobil bzw Desktop. Man kann dann auch mal ganz ketzerisch fragen, was denn "mobil" eigentlich heißt? Geht es um die Displaygröße, um den Touchscreen oder um was noch? Langsame Internetverbindung kann es in heutiger Zeit eigentlich fast nicht mehr sein. Mein Schlepptop ist auch "mobil", gibt sich aber Gott sei Dank als Desktop zu erkennen. Dafür sind dann aber einige Tablets als Mobilgeräte unterwegs, die ein größeres Display haben als mein Schleppy. Nützlich wären eigentlich verschiedene Kriterien, insbesondere die Frage nach Maus oder Touchscreen. Um sicher zu gehen muss man da leider noch andere Dinge abfragen außer der Viewportgröße, oder man verwendet wie mlweb eben Menues, die auch ohne Maus und Javascript bedienbar sind, sonst kommt man auf dem etwas größeren Tablet nicht mehr an eventuelle Unterseiten per Dropdown-Menü dran. Da freut sich der Besucher dann besonders.

Meine Idee, beides zu kombinieren, mobiles Layout und Media-Queries zu verwenden, war unter anderem auch so gedacht, dass ich dann beim "mobilen" Layout grundsätzlich davon ausgehe, dass es ohne Maus bedienbar sein muss und auch alle Informationen ohne "hover" zugänglich sein müssen. Während ich beim Desktop-Layout dann gnadenlos davon ausgehen kann, dass Maus bzw Hover-Effekt verfügbar sind. Beide Layouts werden per CSS und Media-Queries vom Layout her für alle Viewportgrößen tauglich gemacht und für den Notfall, dass irrtümlicherweise für ein Gerät das unpassende Layout geladen wird, gibts dann noch den Umschalter ;).

Aber ich denke mal, die überwiegende Mehrheit der Contao-Webseiten arbeitet nicht mit den mobilen Layouts.

Übrigens, bevor jemand auf die Suche geht nach Touch-Feature-Sniffing, das hatte ich vor ca einem Jahr mal ausgiebig recherchiert mit dem Ergebnis, dass es nicht möglich ist. Man kann nicht herausfinden welche Eigenschaften das visuelle Ausgabegerät des Besuchers hat.

Zitat:

---

Zitat von Andreas

Was ich noch nicht richtig getestet haben ist, ob z.B. eine große Hintergrundgrafik, welche ich auf kleinen Viewports nicht anzeigen möchte, durch den media-query background-image:none, auch wirklich nicht geladen wird

---

Speziell getestet habe ich das auch noch nicht. Das war für mich aber bisher entbehrlich. Bei mobile first brauche ich die Eigenschaft eigentlich gar nicht (ist ja der Standard). Erst bei Displays ab einer bestimmten Eigenschaft wird ein Hintergrundbild verwendet und das wird dann auch erst dort geladen.

Zitat:

---

Zitat von Andreas

Unsicherer bin ich mir damit, ob ein Element, welches mit CSS auf display:none gesetzt wird geladen wird, oder nicht. Vielleicht weiß ja der ein oder andere noch mehr dazu.

---

Mein Kenntnisstand: Alles was über display:none ausgeblendet wird, wird geladen nur nicht angezeigt.

Ich habe mal ein paar Tests im FF gemacht.

CSS-Hintergrundbilder mit media-queries scheinen kein Problem zu sein.

PHP-Code:

---

body {
  background-image: url(../../files/testfile.jpg);
}
@media(min-width: 560px) {
  body {
    background-image: none;
  }
} 


---

Aufm Desktop sehe ich das Bild nicht und es ist auch nicht geladen. Wenn ich den Viewport jetzt auf 560px zusammenschiebe kann man in den Dev-Tools sehen, wie das Bild dann erst nachgeladen wird.

---

Auch das hier funktioniert

PHP-Code:

---

#main {
  display: none;
}
#main .inside {
  background-image: url(../../files/testfile.jpg);
} 


---

Das Bild wird nicht geladen, weil das Elternelement auf display:none steht. Direkt mit dem Hintergrund auf #main dann natürlich auch.

---

Das hier funktioniert nicht, das Bild wird trotzdem geladen.

HTML-Code:

---

<img src="files/testfile.jpg" alt="" style="display:none;">

---

Danke für Deine Tests.

Zitat:

---

Zitat von Andreas

Das hier funktioniert nicht, das Bild wird trotzdem geladen.

HTML-Code:

---

<img src="files/testfile.jpg" alt="" style="display:none;">

---

---

Genau einen solchen Fall meinte ich mit "Alles was über display:none ausgeblendet wird, wird geladen nur nicht angezeigt."
Ich hätte vielleicht besser schreiben sollen, dass die Inhalte trotzdem geladen werden.
Auch bei dem untenstehenden Beispiel wird das Bild geladen, aber nicht angezeigt.

HTML-Code:

---

<div style="display:none;">
<img src="files/testfile.jpg" alt="" ></div>

---

Dein Beispiel mit einen Elternelement display:none und einem "leeren" Kindelement mit Hintergrundbild betrachte ich in dem Zusammenhang eher als "Sonderfall".

Zitat:

---

Zitat von mlweb

Dein Beispiel mit einen Elternelement display:none und einem "leeren" Kindelement mit Hintergrundbild betrachte ich in dem Zusammenhang eher als "Sonderfall".

---

Ne, das Element war nicht leer. Ich wollte auch nicht gegen deine Aussage sprechen, sondern habe nur ein paar Tests gemacht.

Als Fazit zumindestens für den FF kann man sagen, dass die CSS-Hintergrundbilder sehr intelligent gehandhabt werden. Was nicht angezeigt werden muss, wird auch nicht geladen. Dagegen findet kein Zusammenspiel zwischen HTML und CSS statt, was die Ressourcen betrifft - also ein IMG schert sich nicht um das CSS, es wird geladen, wenn es im Quelltext steht.

Man könnte diesen Umstand jetzt z.B. dazu nutzen, dass man eine Galerie ohne IMGs sondern nur mit CSS-BG-Bildern erstellt. Wenn man diese Galerie dann für schmale Viewports auf display:none setzt, werden sie auch nicht geladen. Ob das jetzt irgendwie Sinn macht weiß ich nicht, wollte es nur erwähnt haben, weil es auch das Beispiel mit dem Elternelement auf display:none widerspiegelt.

Zitat:

---

Zitat von Andreas

Man könnte diesen Umstand jetzt z.B. dazu nutzen, dass man eine Galerie ohne IMGs sondern nur mit CSS-BG-Bildern erstellt. Wenn man diese Galerie dann für schmale Viewports auf display:none setzt, werden sie auch nicht geladen. Ob das jetzt irgendwie Sinn macht weiß ich nicht, wollte es nur erwähnt haben, weil es auch das Beispiel mit dem Elternelement auf display:none widerspiegelt.

---

In meinen Augen macht so etwas eher keinen Sinn.
Ich halte es aus Gründen der Semantik, der Usability und Accessibility grundsätzlich für wichtig, dass Inhaltsbilder ins HTML gehören. Dagegen gehören Bilder die als grafische Gestaltungselemente dienen als Hintergrundbilder ins CSS.
Eine Galerie als reines Gestaltungselement ohne inhaltliche Relevanz, kann ich mir ehrlich gesagt nicht vorstellen. Vielleicht reicht ja auch meine Phantasie dazu nicht.

Stimme dir voll und ganz zu.

Wie haltet ihr das momentan bei großen Hintergrundbildern (Seitenhintergrund)? Ich bin da gerade dran, für einen Kunden sowas zu machen. Bildqualität ist ihm relativ wichtig. Ich weiss, dass es für "echte" CSS-Hintergrundbilder in CSS3 Support gibt mit image-set. Aber der Browser-Support ist noch nicht besonders groß. Bei srcset sieht es wesentlich besser aus. Ich bin jetzt am Überlegen, ob ich das nicht mit normalen Bildern machen soll zwecks besserer Bildqualität auf Retina Displays. Allerdings teile ich auch eure Bedenken wegen inhaltlicher Relevanz usw. Obwohl die Bilder zumindest teilweise schon konkreten Bezug zum Seiteninhalt haben. Momentan tendiere ich allerdings dazu, ganz normale CSS-Hintergrundbilder zu nehmen und mit image-set die bessere Qualität zu ermöglichen für die Browser, die das können.

@peter.fl

Ich persönlich habe für Kunden genauso wie @Andreas noch nie ein mobiles Layout eingesetzt. Schon bevor es media-queries gab, habe ich auf Fluid- bzw. Elastic-Layout gesetzt. Damit ist mir der Umstieg auf responsive Design relativ leicht gefallen.
Für mich ist das entscheidende Argument, dass es eine Bevormundung ist, wenn ich Nutzern, deren Gerät sich als mobiles Gerät "outet" nur eine abgespeckte Version der Website anbiete.
Es mag Anwendungen geben, wo es sinnvoll ist, mit einer mobilen Website oder einen mobilen App zu arbeiten. Für die meisten Websites ist aber m.E. die Konzentration auf das Wesentliche und eine gut durchdachte Strukturierung der Inhalte der bessere Weg um Webseiten auf jedem erdenklichen Endgerät gut bedienbar zu machen. Für möglichst kurze Ladezeiten sorgen dann

• optimierte Bilder
• responsive Bilder
• kleine CSS-Dateien - ich nutze z.B. kein Framework, wie Bootstrap
• gut strukturierte HTML-Dateien - dafür sorgt eigentlich Contao sehr gut, wenn man die entsprechenden Templates nicht unprofessional verbiegt

Was mir bei der Strukturierung auch immer sehr wichtig erscheint ist die Überlegung, ob insbesondere im Hinblick auf die mobilen Geräte eine Struktur erforderlich ist, die tiefer als zwei Ebenen geht.

Vielleicht siehst Du aus diesen paar Überlegungen schon, dass der Inhalt im Vordergrund steht. Ich "zwinge" meine Kunden dazu sich zuerst mit dem Inhalt zu beschäftigen. Erst wenn ein Grobkonzept des Inhalts steht, fange ich an mir Gedanken darüber zu machen, wie das Ganze optisch aufbereitet werden soll. Obwohl mobile First umgesetzt steht bei den Designüberlegungen häufig das Desktop-Layout zuerst oder es wird parallel entwickelt.

Zitat:

---

Zitat von tab

Momentan tendiere ich allerdings dazu, ganz normale CSS-Hintergrundbilder zu nehmen und mit image-set die bessere Qualität zu ermöglichen für die Browser, die das können.

---

Habe bisher damit nur experimentiert ein konkretes Kundenprojekt hat sich für mich noch nicht ergeben. Ich würde aber auch dazu tendieren.

Dagegen spricht aus meiner Sicht nur die schwierigere Austauschbarkeit der Bilder durch den Kunden. Bei einem "echten" Bild hat man die Bildgrößen zur Verfügung und kann das Bild mit dem Picker einfach auswählen. Die notwendigen Bildgrößen werden dann automatisch erzeugt. Das geht bei der image-set Lösung eben nicht. Der interne CSS-Editor unterstützt es nicht und somit müssen die einzlenen Bildgrößen selbst erzeugt, hochgeladen und dann die Pfade im CSS angepasst werden. Werde ich wohl nicht umhin kommen, eine "Pflegeanleitung" zu schreiben ;). Aber eine kleine Schulung wird sowieso notwendig sein und Schulungsunterlagen muss ich eh noch erstellen. Der Kunde möchte eben gewisse Dinge selbst austauschen/aktualisieren können. Für diese Dinge wie Bilder und PDF-Dateien sollte der Austausch halt möglichst einfach sein. Am einfachsten wird wohl sein, für die Hintergrundbilder Dateinamen und Ordner fest vorzugeben.

Zitat:

---

Zitat von tab

Wie haltet ihr das momentan bei großen Hintergrundbildern (Seitenhintergrund)?

---

Bis jetzt habe ich, wenn gewünscht, auf kleinen Viewports das Hintergrundbild einfach abgeschaltet.

Mir kommt aber gerade sone Idee. Man könnte doch [pageimage] soweit aufbohren, dass diese Erweiterung, wenn man auf einer Seite ein Bild auswählt, dynamisch eine CSS-Datei erzeugt, anstatt das Inline-Style in die Seite zu schreiben. Dann könnte man beim Erstellen dieser CSS direkt passende kleinere Bilder erzeugen und mit media-queries in diese CSS bringen. In den Einstellungen der Seiten müsste man dann zusätzlich zu der Auswahl des Bildes die Möglichkeit haben Breakpoints und die Bildgrößen angeben zu können.

Vor kurzem gab es doch hier einen Thread (https://community.contao.org/de/show...sten-umsetzten), da ging es um Austausch von Hintergrundbildern durch den Kunden bei jedem Artikel. Da wurde auch eine Lösung mit Dateipicker und Nutzung eines Inhaltsbildes, welches dann als Hintergrundbild verwendet wird angesprochen. Vielleicht findest Du da eine Anregeung.

ich habe das Problem für mich so gelöst:

als Modul z.B. ein Hintergrundbild mit 1x1 Pixeln einbinden und immer laden lassen. Das geht extrem fix wenn man auf das richtige Format achtet.
Per CSS setze ich das Dummy-Bild auf "display:none" und füge das für diese mediaquerie passende Bild einfach ein. "background-image: url(files/css/testfile.jpg)"

Soweit ich das eroieren konnte, wird dann tatsächlich NUR das Bild nach geladen, was zur mediaquerie gehört und halt das 1x1 Bild.

Dann kannst du auch komplett auf die Erweiterung bzw. das eingebundene Bild verzichten und das CSS-Hintergrundbild direkt dem HTML, BODY, #wrapper oder einem ins Layout einbebauten leeren Container geben.

Bin gerade über diesen Thread gestolpert und auf diese Aussage gestoßen:

Zitat:

---

Zitat von Andreas

Übrigens, bevor jemand auf die Suche geht nach Touch-Feature-Sniffing, das hatte ich vor ca einem Jahr mal ausgiebig recherchiert mit dem Ergebnis, dass es nicht möglich ist. Man kann nicht herausfinden welche Eigenschaften das visuelle Ausgabegerät des Besuchers hat.

---

Hattest du seinerzeit die Media-Queries pointer:coarse bzw :fine und hover:hover bzw. :none in deiner Recherche mit untersucht? Weiß nicht genau, wann die eingeführt wurden, aber ich bin auf einen Artikel auf CSS-Tricks vom Feb. 2017 gestoßen, der die Queries erwähnte. Das scheint mir doch recht praktikabel zu sein, wenn es denn weitreichend unterstützt wird. Ich kann es hier aber nur mit meinem Rechner und Handy testen.

Nachtrag: Browserunterstützung: https://caniuse.com/#feat=css-media-interaction

Nein, das gab es damals wohl noch nicht. Aber modernizer gab es damals schon und es gab gute Gründe, warum es auch damit nicht möglich ist, obwohl in deinem Link erwähnt.

Ich würde diese media queries nicht benutzen. Z.B. habe ich Schwierigkeiten mit den github Seiten, weil die dort hover:none benutzen. Mein Browser hat z.B. hover:none, obwohl ich da mit meiner Maus hovern kann. Evtl. hat er hover:none, weil mein Monitor an ein Laptop mit Touchscreen angeschlossen ist. Sieht also so aus, als würde das CSS den Browser untersuchen und nicht mein Ausgabegerät. Mit dem Laptop kann ich übrigens mit Maus und Eingabepad auch hovern obwohl es einen Touchscreen hat.