"Vererbung" bei Anwendung von Media Queries

[oxo888oxo]

Hallo

Zu Beginn entschuldigt bitte, falls der Betreff irgendwie blöd/falsch ist.
Ich wusste nicht, wie ich meine Frage besser benennen kann.

Beispiel CSS-Datei #1:

  
h1{  
  font-size: 2em;  
}  
[...]  
  
@media only screen and (min-width: 50em) and (max-width: 90em) {  
  h1{  
    font-size: 4em;  
  }  
  [...]  
}  
  
  
@media only screen and (min-width: 90.25em) {  
  h1{  
    font-size: 4em;  
  }  
  [...]  
}  

Hier wird font-size: 4em; ja doopelt verwendet.
Wenn man es aus "@media only screen and (min-width: 90.25em)" herausnimmt, greift dort dann ja wieder font-size: 2em;.
Ist das soweit richtig von mir überlegt?

Falls ja, wäre dann nicht ein folgender Aufbau sinnvoller

  
h1{  
  font-size: 2em;  
}  
[...]  
  
@media only screen and (min-width: 50em) {  
  h1{  
    font-size: 4em;  
  }  
  [...]  
}  
  
@media only screen and (min-width: 90.25em) {  
  [...]  
}  

Hier würde doch dann für Viewport-Größen ab 90.25em erstmal font-size: 4em; aus "@media only screen and (min-width: 50em)" greifen.
Weil doch der CSS-Code von oben nach unten abgearbeitet wird.
Und wenn dann "@media only screen and (min-width: 90.25em)" zur Geltung kommt, dort aber keine Angaben hür h1 drinstehen, wird doch weiterhin "font-size: 4em; angewendet.

Anders ausgedrückt.
Mann fnängt doch ganz oben bei den ersten Angaben in der CSS-Datei immer mit dem an, was erstmal für alle Viewports gelten soll.
Und dann geht man (bei mobile first) zum nächstgrößeren Viewport-Breakpoint und ändert dort alles, was eben anders dargestellt werden soll.
Und beim darauffolgenden Viewport-Breakpoint macht man wieder NUR die Änderungen, die gelten sollen aus Sicht vom zweiten Viewport-Breakpoint.
Ist das richtig überlegt?

Oder sollte man einfach 3 komplett getrenne Media Querie Bereiche machen?
In meinem ersten Beispiel oben ist doch der zweite und dritte Bereich sozusagen getrennt.
Und das erfordert ja wieder mehr Code.

Ich hoffe, ich konnte einigermaßen zum Ausdruck bringen, was ich meine.
Was ist denn da die gescheiteste bzw. korrekte Vorgehensweise?

Gruß
Ingo

[Gunnar Bittersmann]

@@oxo888oxo:

nuqneH

@media only screen and (min-width: 50em) and (max-width: 90em) {
@media only screen and (min-width: 90.25em) {

Und was passiert zwischen 90em und 90.25em?

Das ist richtig dumm spezifiziert worden!!! (Und wer sagt, drei Anführungszeichen seien zu viel: Hier sind drei eher noch zu wenig. Und wer sagt, sie seien ein Zeichen eines kranken Geistes. Ja! Aber nicht meines, sondern des der Ersteller der Spec.)

min-width und max-width hätten entweder so: min-width ≤ current-width < max-width
oder so: min-width < current-width ≤ max-width
wirken sollen, nicht aber so: min-width ≤ current-width ≤ max-width.

Wenn man es aus "@media only screen and (min-width: 90.25em)" herausnimmt, greift dort dann ja wieder font-size: 2em;.
Ist das soweit richtig von mir überlegt?

Ja, richtig.

Falls ja, wäre dann nicht ein folgender Aufbau sinnvoller
…
Und wenn dann "@media only screen and (min-width: 90.25em)" zur Geltung kommt, dort aber keine Angaben hür h1 drinstehen, wird doch weiterhin "font-size: 4em; angewendet.

Ja, sinnvoller.

Mann fnängt doch ganz oben bei den ersten Angaben in der CSS-Datei immer mit dem an, was erstmal für alle Viewports gelten soll.
Und dann geht man (bei mobile first) zum nächstgrößeren Viewport-Breakpoint und ändert dort alles, was eben anders dargestellt werden soll.
Und beim darauffolgenden Viewport-Breakpoint macht man wieder NUR die Änderungen, die gelten sollen aus Sicht vom zweiten Viewport-Breakpoint.
Ist das richtig überlegt?

Ja, richtig.

Oder sollte man einfach 3 komplett getrenne Media Querie Bereiche machen?

Eher nicht. Zumal das bei Breakpoints in em schwierig ist, s.o.

Qapla'

[Tabellenkalk]

Pssst,

spezifiziert worden!!! (Und wer sagt, drei Anführungszeichen

Anführungszeichen sehen etwa so aus: „“, o.ä.
Du willst vermutlich Ausrufezeichen kaufen: !
ich hätte da noch welche, hinten im Schrank.

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk:

nuqneH

Anführungszeichen sehen etwa so aus: „“

Bloß gut, dass du nicht so " gesagt hast!!!

Du willst vermutlich Ausrufezeichen kaufen: !
ich hätte da noch welche, hinten im Schrank.

Ich nehm ein Dutzend; meine sind schon fast alle!!!

Qapla'

[oxo888oxo]

Ja, sinnvoller.

OK prima.
Dann bin ich ja froh, dass ich mir das alles soweit richtig überlegt habe.

Zumal das bei Breakpoints in em schwierig ist, s.o.

Meinst Du damit, dass die Verwendung von em bei Breakpoints nicht so super ist?
Birgt das wieder zu viele "Gefahren" bezüglich der Voreingestelleten CSS der diversen Devices?
Sollte man bei den Media Queries Breakpoints also liebermit Pixel-Angaben arbeiten?

[Gunnar Bittersmann]

@@oxo888oxo:

nuqneH

Meinst Du damit, dass die Verwendung von em bei Breakpoints nicht so super ist?

Nein, das meine ich nicht.

Ich meine, dass @media (max-width: a) {} @media (min-width: a + ε) {} nicht so super ist.

Sollte man bei den Media Queries Breakpoints also liebermit Pixel-Angaben arbeiten?

Nein.

Qapla'

[1UnitedPower]

Meine Herren!

  
@media (max-width: a) {}  
@media (min-width: a + ε) {}  

~~~ nicht so super ist.  
  
Könnten wir das nicht auflösen durch:  
  
~~~css
@media (max-width: a) {}  
@media all and not (max-width: a) {}

[Auge]

Hallo

Zumal das bei Breakpoints in em schwierig ist, s.o.

Meinst Du damit, dass die Verwendung von em bei Breakpoints nicht so super ist?
Birgt das wieder zu viele "Gefahren" bezüglich der Voreingestelleten CSS der diversen Devices?

Es kann sich ergeben, dass du für verschiedene Bereiche verschiedene Breakpoints brauchen wirst.

Angenommen, die Hauptnavigation wird bei schmalen Viewports zum Ausklappen sein, dann bei (spekulativ angenommenen) 28em auf eine mehrspaltige Blockanzeige und bei 42em auf eine horizontale Liste geändert. Das umschalten von Hintergrundbildern und der Anzahl der Spalten, in denen der eigentliche Inhalt der Seite angezeigt wird, kann aber an anderen Breakpoints erfolgen. Deshalb sollten bei jedem der Breakpoints nur die Regeln notiert werden, deren Werte sich dort auch wirklich ändern.

Tschö, Auge

[Matthias Apsel]

Om nah hoo pez nyeetz, Auge!

Deshalb sollten bei jedem der Breakpoints nur die Regeln notiert werden, deren Werte sich dort auch wirklich ändern.

Und das darf, wenn eine Grafik die Referenz ist, durchaus auch eine Angabe in px sein.

Matthias

[Gunnar Bittersmann]

@@Matthias Apsel:

nuqneH

Und das darf, wenn eine Grafik die Referenz ist, durchaus auch eine Angabe in px sein.

Wieso sollte bei responsive design (“flexible media”) Pixel irgendeine Rolle spielen?

Qapla'

[Auge]

Hallo

Und das darf, wenn eine Grafik die Referenz ist, durchaus auch eine Angabe in px sein.

Wieso sollte bei responsive design (“flexible media”) Pixel irgendeine Rolle spielen?

„darf“, nicht „soll“ (im Konjunktiv). Es scheint, dass dir das Pixel derart verhasst ist, dass du es am liebsten verbieten und aus dem kollektiven Gedächtnis der Menschheit verbannen würdest. Hast du dazu eventuell einen passenden, dich selbst zitierenden Link?

Tschö, Auge

[Gunnar Bittersmann]

@@Auge:

nuqneH

Es scheint, dass dir das Pixel derart verhasst ist, dass du es am liebsten verbieten und aus dem kollektiven Gedächtnis der Menschheit verbannen würdest. Hast du dazu eventuell einen passenden, dich selbst zitierenden Link?

Einen passenden, aber nicht mich selbst zitierenden.

Qapla'

[Auge]

Hallo

Es scheint, dass dir das Pixel derart verhasst ist, dass du es am liebsten verbieten und aus dem kollektiven Gedächtnis der Menschheit verbannen würdest. Hast du dazu eventuell einen passenden, dich selbst zitierenden Link?

Einen passenden, aber nicht mich selbst zitierenden.

Zwar einer der üblichen Verdächtigen, wenn du dich schon nicht selbst zitierst, aber sei's drum. In Zukunft also nur noch „Es gibt keine Pixel!“? Ab wievielen Beteiligten darf man sowas als Religion anmelden?

Tschö, Auge

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunnar Bittersmann!

Wieso sollte bei responsive design (“flexible media”) Pixel irgendeine Rolle spielen?

Folgendes Beispiel:

Man hat ein Hintergrundbild, 500px breit, welches man zentriert haben möchte. Erst, wenn es nicht mehr passt, soll es (mit ein wenig Abstand links und rechts) skaliert werden.

#elem {  
       background-image: url("…");  
       background-position: top center;  
}  
  
@media screen and (max-width: 500px) {  
	#elem {  
		background-size: 94% auto;  
	}

Matthias

[Matthias Apsel]

Om nah hoo pez nyeetz, Matthias Apsel!

#elem {

background-image: url("…");
       background-position: top center;
}

@media screen and (max-width: 500px) {
#elem {
background-size: 94% auto;
}

  
bräuchte man nicht, wenn es `max-background-size`{:.language-css} gäbe.  
  
Matthias

-- 
Der Unterschied zwischen Java und JavaScript ist größer als der zwischen [Feme und Femen](http://selfhtml.apsel-mv.de/java-javascript/index.php?buchstabe=F#feme).  
![](http://www.billiger-im-urlaub.de/kreis_sw.gif)  

[Gunnar Bittersmann]

@@Auge:

nuqneH

Es kann sich ergeben, dass du für verschiedene Bereiche verschiedene Breakpoints brauchen wirst.

Angenommen, die Hauptnavigation wird bei schmalen Viewports zum Ausklappen sein, dann bei (spekulativ angenommenen) 28em auf eine mehrspaltige Blockanzeige und bei 42em auf eine horizontale Liste geändert. Das umschalten von Hintergrundbildern und der Anzahl der Spalten, in denen der eigentliche Inhalt der Seite angezeigt wird, kann aber an anderen Breakpoints erfolgen.

Ja. Man sollte aber drauf achten, dass die Komponenten der Seite bei allen Viewportbreiten auch ein stimmiges Gesamtbild ergeben. So kann eine Beschränkung auf wenige Breakpoints aus Design-Sicht sinnvoll sein.

Aus QA-Sicht ist sie es bestimmt.

Qapla'

[Auge]

Hallo

Es kann sich ergeben, dass du für verschiedene Bereiche verschiedene Breakpoints brauchen wirst.

Ja. Man sollte aber drauf achten, dass die Komponenten der Seite bei allen Viewportbreiten auch ein stimmiges Gesamtbild ergeben. So kann eine Beschränkung auf wenige Breakpoints aus Design-Sicht sinnvoll sein.

Aus QA-Sicht ist sie es bestimmt.

Klar, dass man es nicht mit -zig Breakpoints übertreiben sollte. Nicht nur wegen der Qualitätssicherung [1]. Und auch nicht nur der Übersichtlichkeit des Codes wegen. Wenn sich die Ansicht alle paar Breitenpixel [2] andauernd ändert, wird das die Besucher auch eher verwirren als erfreuen.

[1] Ich musste deinem „QA“ tatsächlich hinterhergoogeln, um zu erfahren, was es heißt. Nicht so toll in Sachen User Experience.
[2] Da ist es wieder, das Unwort.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge:

nuqneH

Wenn sich die Ansicht alle paar Breitenpixel [2] andauernd ändert, wird das die Besucher auch eher verwirren als erfreuen.

Normale[tm] Nutzer werden kaum ihr Browserfenster groß- und kleinziehen, um zu sehen, wie responsiv eine Webseite ist. Das tun nur Nerds wie wir. ;-)

Nutzer verwenden verschiedene Geräte, Hoch- und Querformat … und erwarten, dass die Seite bei jeder Viewportbreite gut dargestellt wird. (Wobei „bei jeder Viewportbreite“ in ihrem Denken nicht vorkommt.)

[1] Ich musste deinem „QA“ tatsächlich hinterhergoogeln, um zu erfahren, was es heißt. Nicht so toll in Sachen User Experience.

Oops. In meiner Blase ist das eine gängige Abkürzung.

Qapla'

[Auge]

Hallo

Wenn sich die Ansicht alle paar Breitenpixel andauernd ändert, wird das die Besucher auch eher verwirren als erfreuen.

Normale[tm] Nutzer werden kaum ihr Browserfenster groß- und kleinziehen, um zu sehen, wie responsiv eine Webseite ist. Das tun nur Nerds wie wir. ;-)

Schon klar, aber das meinte ich nicht.

Nutzer verwenden verschiedene Geräte, Hoch- und Querformat … und erwarten, dass die Seite bei jeder Viewportbreite gut dargestellt wird. (Wobei „bei jeder Viewportbreite“ in ihrem Denken nicht vorkommt.)

Ich wollte auf die verschiedenen Geräte hinaus. Man hat ja gerne mal drei oder mehr Geräte in betrieb. Auf einzelnen schraube ich regelmäßig an den Fenstergrößen, schon weil ich den Platz brauche oder Daten aus mehreren Fenstern im Blick haben will.

[1] Ich musste deinem „QA“ tatsächlich hinterhergoogeln, um zu erfahren, was es heißt.

Oops. In meiner Blase ist das eine gängige Abkürzung.

Hehe, ich muss mich auch des öfteren zwingen, nicht aus Gewohnheit mit Fachbegriffen um mich zu werfen, wie nichts Gutes.

Tschö, Auge

[molily]

Hallo,

Sollte man bei den Media Queries Breakpoints also liebermit Pixel-Angaben arbeiten?

Man sollte für Breakpoint i.d.R. die Einheit verwenden, die auch für Schriftgrößen sowie Container- und Spaltenbreiten verwendet wird.

Denn aus den Schwellwerten ergibt sich, welche Inhalte nebeneinander dargestellt werden, und diese Inhalte haben bestimmte Größen, seien es auch nur angestrebte. (Prozentwerte z.B. sind keine festen Größen, aber man geht davon aus, dass der berechnete Wert eine gewisse Mindestbreite hat.)

Beispiele: Zwei Spalten mit 50% haben gewisse Inhalte, die sich erst ab 60em sinnvoll nebeneinander darstellen lassen. Eine kurze Seitenleiste mit 10em hingegen kann ruhig links oder rechts floaten, wenn daneben noch 20em für den Fließtext frei sind.

In welcher Einheit man diese Verhältnisse ausdrückt, ist erst einmal wurscht, denn es geht nur um die Verhältnisse. (r)em anstatt px zu verwenden hat Vor- und Nachteile auf anderen Gebieten. (r)em eignet sich, um die ganze Seite zentral zu skalieren, wenn Schrift- und Containergrößen darin notiert sind.

Mathias

[oxo888oxo]

Man sollte für Breakpoint i.d.R. die Einheit verwenden, die auch für Schriftgrößen sowie Container- und Spaltenbreiten verwendet wird.

Ja alles klar. Danke Euch allen für die nette Hilfe wieder.
Ich habe das nun so umgesetzt und freue mich über den wieder etwas schlanker geworenen CSS-Code.