@@delbor
Beabsichtigt ist: die beiden kleineren Boxen sollen in jedem Fall auf 16:9 und 3:4- Bildschirmen untereinander dargestellt werden. Um die Darstellung auf einem Tablet/iPad/Smartphon kümmere ich mich zu einem späteren Zeitpunkt.
?? iPads haben Displays mit Seitenverhältnis 3:4. iPhones haben ab dem 5er 16:9-Displays.
Wa genau wolltest du damit sagen? Dass du erst für große Bildschirme entwickelst und dich zu einem späteren Zeitpunkt um kleinere kümmerst?
Das kann nur schiefgehen, wie Brad Frost anschaulich illustriert. (Quelle: Brad Frost, The Many Faces of ‘Mobile First’)
Entwickle mobile first – erst für kleine Geräte, um die großen kümmerst du dich später!
Der Grund ist: es soll möglichst schlankes CSS ausgegeben werden. Von daher macht es keinen Sinn, an einen Desktop Handy- oder Tablet-CSS auszuliefern.
Mikrooptimierung an der falschen Stelle. Wenn du Bytes sparen willst (und das solltest du), kümmere dich um die Optimierung der Bilder. Die paar Bytes im Stylesheet sind kaum der Rede wert.
Und wie soll der Server auch wissen, ob an der anderen Seite der Leitung ein Desktop-PC oder Smartphone ist?
User agent sniffing? Vergiss es!
Und falls du an sowas wie
<link rel="stylesheet" href="small.css" media="(max-width: 20em)"/>
<link rel="stylesheet" href="big.css" media="(min-width: 20em)"/>
dachtest: Nein, Browser laden dann beide Stylesheets.
Der Server kann gar nicht wissen, welche Styleregeln der Client braucht. Du kommst nicht drumrum, alle auszuliefern. (Es sei denn, du willst das mit JavaScript verkomplizieren.)
Nachtrag: Hüte dich davor, in Kategorien „Desktop-PC“, „Tablet“, „Smartphone“ zu denken – das führt zu nichts. Die Übergänge sind fließend, mit Schubladen kommt man da nicht weiter.
Breakpoint in media queries sollten sich nach dem Inhalt richten, nicht nach irgendwelchen Geräteklassen. (siehe auch)
LLAP 🖖
“I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl