media-queries

[Lydia]

Guten Tag zusammen,
folgendes habe ich gefunden

@media (30em <= width <= 50em )

Ist neben dem <= auch < erlaubt? Dies wäre nämlich nötig, wenn ich etwa folgendes habe:

Query1:

@media (15em <= width <= 30em ) ...

Query2:

@media (30em < width <= 40em ) ...

[JürgenB]

Hallo Lydia,

Query1:

@media (15em <= width <= 30em ) ...

Query2:

@media (30em < width <= 40em ) ...

wenn ich https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#syntax_improvements_in_level_4 richtig verstanden habe, geht beides.

Aber das ist Media Queries Level 4, das wird z.Zt. nur vom Firefox unterstützt: https://caniuse.com/mdn-css_at-rules_media_range_syntax.

Gruß
Jürgen

[Lydia]

Hallo Jürgen,

wenn ich https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#syntax_improvements_in_level_4 richtig verstanden habe, geht beides.

woraus schließt Du dies? Ich finde dort kein < sondern nur <=.

[Auge]

Hallo

wenn ich https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#syntax_improvements_in_level_4 richtig verstanden habe, geht beides.

woraus schließt Du dies? Ich finde dort kein < sondern nur <=.

Das sind Beispiele. Wenn <= möglich ist, ist es auch <.

Tschö, Auge

[JürgenB]

Hallo Lydia,

wenn ich https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#syntax_improvements_in_level_4 richtig verstanden habe, geht beides.

woraus schließt Du dies? Ich finde dort kein < sondern nur <=.

siehe https://www.w3.org/TR/mediaqueries-4/#mq-range-context

Gruß
Jürgen

[Rolf B]

Hallo Lydia,

auf einer allgemeinen Beschreibungsseite kannst du keine umfassende Darstellung erwarten.

Für eine verbindliche Auskunft musst Du ohnehin zur Spezifikation. Da es eine Candidate Recommendation ist, dürfte sie auch ziemlich stabil sein - bei einem Draft könnte sich eher noch etwas ändern.

Aber auch bei Mozilla steht es vollständig, man muss nur auf die Seite gucken, die @media definiert: https://developer.mozilla.org/en-US/docs/Web/CSS/@media

Rolf

[Lydia]

Hi,
besten Dank an alle.
Nachdem die Variante bisher nur im Firefox möglich ist, verwende ich also die Möglichkeit

@media screen (min-width: 30em).....

@media screen (min-width: 40em).....

Ist die Reihenfolge belanglos oder empfiehlt sich vielleicht die absteigende Reihenfolge 40em, 30em?

[Matthias Scharwies]

Servus!

Hi,
besten Dank an alle.
Nachdem die Variante bisher nur im Firefox möglich ist, verwende ich also die Möglichkeit

@media screen (min-width: 30em).....

@media screen (min-width: 40em).....

Ist die Reihenfolge belanglos oder empfiehlt sich vielleicht die absteigende Reihenfolge 40em, 30em?

Nein, so wie du es gemacht hast:

1. Mobile first! (keine Festlegungen)
2. @media screen (min-width: 30em){} (einige Elemente nebeneinander)
3. @media screen (min-width: 40em){} (weitere Elemente nebeneinander)

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Lydia,

nein, die Reihenfolge ist nicht belanglos, bzw. sie ist unmittelbar vom Konzept deines Seitenaufbaus abhängig.

CSS bildet Prioritäten, die entscheiden, welche Regel Vorrang bekommt, wenn zwei Regeln die gleiche Eigenschaft setzen. Das ist gar nicht so leicht. Unse r Wiki hat einen Artikel zu den Schlüsselbegriffen Kaskade und Spezifität.

TL;DR: Wenn zwei Regeln die gleiche Prio haben, gewinnt die letzte.

Es gibt zwei Vorgehensweisen beim responsiven Design:

Big Screen First

Du designest deine Seite für einen Desktop-Bildschirm und erkennst über Media-Queries, dass der Platz nicht reicht. In den @media Abschnitten fügst Du Styles hinzu, die das Layout auf "schmal" umbauen.

In diesem Fall beginnst Du mit den breiteren Media-Abfragen.

Mobile First

Du designest deine Seite so, dass sie ohne Media-Abfragen auf einem schmalen Bildschirm gut aussieht. Mit @media-Abfragen baust Du das schmale Design in das breite um ; In diesem Fall beginnst Du mit dem schmalerern Media-Abfragen.

Empfohlen ist der Mobile First Ansatz - oder bei anderen Medienmerkmalen - Simple First. Nicht jede Media-Abfrage wird von jedem Browser unterstützt, und du möchtest ja auf einem "schlechteren" Browser dein Layout nicht zerreißen. Deswegen wählt man den Weg, zunächst ein Basislayout zu bauen und dies je nach Endgerät zu verbessern. Stichwort: Progressive Enhancement.

Zum Design von Media-Abfragen gibt es ebenfalls zwei Ansätze: Überlappend und nicht überlappend.

Nicht überlappend:

Du fragst Intervalle ab. Zone 1: (min-width: 30em) and (max-width: 50em), Zone 2: (min-width: 50em). Vorteil: Es gelten nicht so viele Styleregeln gleichzeitig. Bei umfangreichem CSS kann das ein Performancevorteil sein. Nachteil: Du musst ggf. etliche Styles für beide Breitenbereiche doppeln. Und du hast ein Problem: max-width schließt 50em ein, d.h. die Medienabfragen überlappen sich bei genau 50em Breite und Du hast Breite, wo beide Bereiche gelten.

Media Queries Level 4 vereinfachen die nicht überlappende Konstruktion durch die mathematische Formulierung und Bereichsabfragen. Aber die funktionieren noch nicht gut. In Chrome gar nicht, und Firefox kann weder Intervallabfragen noch Abfragen mit dem Wert vor dem Featurenamen.

@media (30em <= width < 50em) {
   ...
}

@media (50em <= width) {
   ...
}

Firefox kann immerhin dies hier:

@media (width >= 30em) and (width < 50em)
   ...
}

@media (50em <= width) {
   ...
}

Überlappend:

Du machst aus der Not eine Tugend und fragst nur mit min-width. Also genau so, wie es in deiner Frage steht. In der breitesten Zone gelten dann alle Media-Abfragen. Vorteil: Die Logik ist nicht so kompliziert und Du musst keine Styles doppeln, die in beiden Bereichen gelten sollen. Nachteil: Du musst in der breiten Zone ggf. CSS Regeln notieren, die Styles aus der mittleren Zone wieder rückgängig machen. Unter dem Strich ist so mehr CSS wirksam und belastet den Browser mehr. Das fällt aber nur auf Seiten mit sehr viel Markup und Styles ins Gewicht.

Rolf

[Matthias Scharwies]

Rolf schrieb:

nein, die Reihenfolge ist nicht belanglos, ...

Das müsste man genauso ins Wiki kopieren! Ich hatte vorhin nach Mobile First gesucht und dies gefunden:

• Mobile_First

• HTML/Tutorials/responsive_Webdesign/Vorüberlegungen#Mobile_first

• CSS/Tutorials/Einstieg/Media_Queries#Media_queries

Ich glaube, dass passt am besten in das RWD-Tutorial!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

mach ich

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

mach ich

Vielen Dank! Sonst wär ich aktiv geworden!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

hab die Reihenfolgeproblematik jetzt hier diskutiert:

https://wiki.selfhtml.org/wiki/CSS/Tutorials/Einstieg/Media_Queries

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

hab die Reihenfolgeproblematik jetzt hier diskutiert:

https://wiki.selfhtml.org/wiki/CSS/Tutorials/Einstieg/Media_Queries

Danke!

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Rolf B

Big Screen First

Du designest deine Seite für einen Desktop-Bildschirm …

Mobile First

… auf einem schmalen Bildschirm

Desktop heißt ebensowenig großer Bildschirm wie Mobile kleiner Bildschirm heißt.

Desktop 400% gezoomt bspw. ist ein schmaler Bildschirm.

Handy im Querformat könnte schon ein breiter Bildschirm sein.

---

Unter dem Strich ist so mehr CSS wirksam und belastet den Browser mehr.

Ist das so?

Das fällt aber nur auf Seiten mit sehr viel Markup und Styles ins Gewicht.

Und selbst wenn: So viel Markup und Styles kann es kaum geben, dass das ins Gewicht fällt.

😷 LLAP

[Rolf B]

Hallo Gunnar,

Ist das so?

Das war meine Hypothese angesichts des Threads "CSS Performance".

Und wir hatten in der Firma eine Webanwendung, die sehr viel CSS genutzt hat und den IE damit in die Knie zwang. Es wurde auf Firefox umgestellt und die Schwuppdizität war wieder da. Ich würde daraus nicht folgern, dass umfangreiches CSS für den Firefox kein Problem ist. Nur, dass die Trägheitsschwelle höher liegt.

So viel Markup und Styles kann es kaum geben, dass das ins Gewicht fällt

Sehe ich ähnlich - ich bin aber zu faul, hier Versuche für die Schwelle zu machen, ab der es problematisch wird.

Rolf

[Rolf B]

Hallo Rolf,

Update zur Kompatibilität. Abfrage mit Operatoren und Range-Abfragen sind noch nicht breit genug verwendbar.

Rolf

[Lydia]

Guten Tag zusammen,
nachdem dies

@media (30em <= width <= 50em )

noch nicht sehr unterstützt wird, heißt es ja

1. Definition für schmale viewports, dann z.B.

2. @media screen (min-width: 30em){}

3. @media screen (min-width: 40em){}

Es gilt neben einer anderen Regel auch immer die für schmale viewports. In diesem thread wurde auch die Performance angesprochen. Wäre es dann nicht sinnvoll zu schreiben:

1. @media screen (max-width: 30em){}

2. @media screen (min-width: 30em){}

3. @media screen (min-width: 40em){}

Dann bestünde das Problem ja nur bei exakt 30em.

Bleibt gesund!

[Rolf B]

Hallo Lydia,

Dann bestünde das Problem ja nur bei exakt 30em.

Und das ist genau eins zu viel. Damit hast Du nicht 3, sondern 4 Fälle, für die Du entwickeln und testen musst.

In diesem thread wurde auch die Performance angesprochen

Ja. Mit der Aussage: Das ist nur in Ausnahmefällen ein Problem. Bei sehr viel HTML und CSS. SEHR viel. Keine Ahnung wieviel 100KB Du da an Regeln zusammentragen musst, um in Grenzbereiche zu kommen.

Man kann versuchen, die Überlappung bei 30em zu vermeiden. Mit Neunerorgien wie "max-width: 29.99999em". Ich habe hier dazu einen Kommentar eingetragen:

Wenn Sie Lotto spielen möchten, ist Webdesign der falsche Ort dafür.

Überlappungsfreie Medienbereiche führen vor allem zu Style-Dopplungen. Die sind dann zwar nicht alle aktiv, aber Du musst sie bei der Seitenpflege beachten. Eine wichtige Abkürzung beim Softwarebau lautet: DRY. Don't Repeat Yourself.

Rolf

[Lydia]

Hallo Lydia,

Dann bestünde das Problem ja nur bei exakt 30em.

Und das ist genau eins zu viel. Damit hast Du nicht 3, sondern 4 Fälle, für die Du entwickeln und testen musst.

Das verstehe ich nun gar nicht mehr.

Mit und ohne

@media screen (max-width: 30em){}

gilt die schmale Definition solange width < 30em.

Ab 30em gilt ohne mein Vorschlag die schmale Definition (da keine Einschränkung) und es gilt die Definition für 30em.

Ich muss also testen <30em, >=30em

Mit meinem Vorschlag gelten beide Definitionen nur für den einen Fall 30em, danach gilt meine Regel 1 nicht mehr. Der Fall 30em ist dann doch genau wie der obige Fall. Und wenn > 30em, dann gibt es keine Konkurenzprobleme zwischen zwei Definitionen.

Man kann versuchen, die Überlappung bei 30em zu vermeiden.

Ohne meinen Vorschlag ist doch die Überlappung nicht nur bei 30 sondern bei allem über 30.

[Rolf B]

Hallo Lydia,

@media screen (max-width: 30em){}

gilt die schmale Definition solange width < 30em.

Eben nicht. max-width prüft auf kleiner oder gleich. Je nach Wert für 1em ist der Unterschied zwischen <30em und <=30em 0 oder 1 Pixel breit. Und das lässt Dir beim Ziehen der Fenstergröße ggf. das Layout springen, weil unerwartet die Regeln für <=30em und >=30em gleichzeitig gelten. Oder, wenn die Fenstergröße gerade so gezogen wurde, dass die Breite genau 30em ist, ist dein Layout geschrottet, wenn Du diesen Fall nicht berücksichtigt und getestet hast.

Deswegen hast Du mit deinem Vorschlag von 13:17 Uhr vier Fälle:

< 30em - Regelsatz 1
= 30em - Regelsatz 1 und 2
> 30em und < 40em - Regelsatz 2
>= 40em - Regelsatz 2 und 3

Ohne die max-width:30em Klausel für den "Normalfall" hast Du

< 30em - Regelsatz 1
>= 30em und < 40em, Regelsatz 1 und 2
>= 40em, Regelsatz 1, 2 und 3

Das ist nach meiner Erfahrung besser zu handhaben.

Rolf

[Auge]

Hallo

Hallo Lydia,

@media screen (max-width: 30em){}

gilt die schmale Definition solange width < 30em.

Eben nicht. max-width prüft auf kleiner oder gleich. Je nach Wert für 1em ist der Unterschied zwischen <30em und <=30em 0 oder 1 Pixel breit.

Ah ja, das hatte ich in meiner Antwort übersehen.

Deswegen hast Du mit deinem Vorschlag von 13:17 Uhr vier Fälle:

< 30em - Regelsatz 1
= 30em - Regelsatz 1 und 2
> 30em und < 40em - Regelsatz 2
>= 40em - Regelsatz 2 und 3

Ohne die max-width:30em Klausel für den "Normalfall" hast Du

< 30em - Regelsatz 1
>= 30em und < 40em, Regelsatz 1 und 2
>= 40em, Regelsatz 1, 2 und 3

Dann kann man aber auch beim „alten“ Prinzip bleiben. Meiner Meinung nach liest sich das auch einfacher.

nix - Regelsatz 1
min-width: 30em - Regelsatz 1 und 2
min-width: 40em, Regelsatz 1, 2 und 3

Tschö, Auge

[Lydia]

Hallo

                       Notwendig bei 
  meinem Vorschlag                       Euerem Vorschlag
  Regelsatz 1                            Regelsatz 1   
  Regelsatz 1 und 2                      Regelsatz 1 und 2
  Regelsatz 2                            - 
  Regelsatz 2 und 3                      Regelsatz 1, 2 und 3

Ich bin der Meinung, dass die Komplexität von Regelsatz 1,2,3 gegenüber Regelsatz 2,3 mehr Aufwand bedeutet als die zusätzliche einzelne Regel 2.
Und wenn ich statt 30em die von Rolf angeführte 29.99999em verwende, so würde für mich der Test von Regel 2 sogar wegfallen.
Grund:
Wenn man in Kauf nimmt, dass bestimmte selten verwendete Browserversionen nicht mehr unterstützt werden, so kann man getrost die Nutzer ausschließen, deren viewport genau 29.99999em groß ist.

[Rolf B]

Hallo Lydia,

dann mach's halt so, wie Du meinst. Du hast die Informationen erhalten und die Entscheidung ist Deine.

Aber wenn es auf dem Weg am Ende Chaos gibt, komm gerne wieder und frage nach. Ich sage dann gerne: Siehste! 😉

Und wenn es gut geht, freu ich mich auch für Dich.

Rolf

[Lydia]

Wieso Chaos,
bedeutet meine Variante nicht weniger Aufwand?
Mal abwarten, was Gunnar spricht!

[Henry]

Hallo Lydia,

Wieso Chaos,

weil media queries am Ende doch nur ein (vielleicht hilfreiches) Hilfsmittel, eine Krücke ist, die unmöglich alle Geräte und Einstellungen abdecken kann um ein pixelgenaues Ergebnis zu bekommen. Daher mal eine Frage, warum ist dir das so nahezu pixelgenau wichtig?

Gruss
Henry

[Lydia]

Hallo Henry,

Daher mal eine Frage, warum ist dir das so nahezu pixelgenau wichtig?

Ist es doch nicht.

[Gunnar Bittersmann]

@@Lydia

Wieso Chaos,
bedeutet meine Variante nicht weniger Aufwand?

Eher das Gegenteil. Beispiel:

• “mobile first”: einspaltig,
• ab 30em zweispaltig,
• ab 45em größere Schrift
• ab 60em dreispaltig

Mit stacking media queries musst du nur die jeweiligen Änderungen angeben.

Mit non-stacking media queries musst du den ganzen Kram immer wieder wiederholen. Da bleibt kein Auge DRY. 😢

Mal abwarten, was Gunnar spricht!

Ich habe gesprochen. Howgh!

😷 LLAP

[Lydia]

Na, ja, jetzt kommen plötzlich 60em dazu. Die gilt natürlich in beiden Fällen!

[Auge]

Hallo

                       Notwendig bei 
  meinem Vorschlag                       Euerem Vorschlag
  Regelsatz 1                            Regelsatz 1   
  Regelsatz 1 und 2                      Regelsatz 1 und 2
  Regelsatz 2                            - 
  Regelsatz 2 und 3                      Regelsatz 1, 2 und 3

Ich bin der Meinung, dass die Komplexität von Regelsatz 1,2,3 gegenüber Regelsatz 2,3 mehr Aufwand bedeutet als die zusätzliche einzelne Regel 2.

Öhhm, vermutlich verstehst du uns immer noch miss.

In unserem Vorschlag …

• Regelsatz 1
• Regelsatz 1 und 2
• Regelsatz 1, 2 und 3

… enthalten die mehrteiligen Regelsätze von sich aus und ohne erneute Deklaration die vorherigen Regeln. Heißt, bei „Regelsatz 1, 2 und 3“ (zweiter Mediaquery (wo auch immer der ansetzt)) müssen nur die Regeln für 3 notiert werden, weil die Regeln für 1 und 2 bereits vorhanden sind. Für diese Regeln entsteht kein erneuter Aufwand.

Das gilt auch bei deinem Aufbau grundsätzlich für die Fälle …

• Regelsatz 1
• Regelsatz 1 und 2

… aber nicht für die Fälle „Regelsatz 2“ und „Regelsatz 2 und 3“, weil du da – mit einer gewissen Wahrscheinlichkeit und unabhängig davon, ob das in deiner Auflistung so steht – Regeln für 1 explizit aufheben musst (und das für den Fall „Regelsatz 2“ nur für den Bereich von 0.00001em). Das ist in unserem Vorschlag wohl nur in Ausnahmefällen (Tabellen können so ein Fall sein) notwendig.

Und wenn ich statt 30em die von Rolf angeführte 29.99999em verwende, so würde für mich der Test von Regel 2 sogar wegfallen.
Grund:
Wenn man in Kauf nimmt, dass bestimmte selten verwendete Browserversionen nicht mehr unterstützt werden, so kann man getrost die Nutzer ausschließen, deren viewport genau 29.99999em groß ist.

Du weißt ohne weiteres nicht, wie groß irgendein Viewport ist. Bei Mobilgeräten ist der noch von fester Größe, aber es gibt derart viele Gerätetypen, dass du nicht ausschließen kannst, dass da in Kombination mit der auf dem System festgelegten Standardschriftgröße zufällig genau 29.99999em herauskommen.

Auf Desktopsystemen kann nun aber nicht nur die Standardschriftgröße variieren, hier kommt noch hinzu, dass ein Anwender den Browser im Vollbildmodus betreibt, ein anderer aber als Fenster von irgendeiner Größe. Dort ist eine zufällg für 29.99999em Viewportbreite ^[1] passende Kombination der beiden variablen Werte durchaus möglich. Und das auch ganz ohne die Bedingung „bestimmte selten verwendete Browserversion“.

Egal, wie unwahrscheinlich es sein mag, dass jemand in die Falle 29.99999em > Viewportbreite < 30em gerät ^[2], ist es doch so, dass es mit unserem Ansatz grundsätzlich vermieden wird, dem Besucher diese Falle überhaupt zu stellen. Dieses (unwahrscheinliche) Problem existiert in unserem Ansatz schlicht nicht.

Tschö, Auge

---

1. Wir sind uns hoffentlich einig, dass die 29.99999em nur ein Beispielwert sind. ↩︎

2. Ja, das ist sehr unwahrscheinlich. ↩︎

[Auge]

Hallo

Hallo Lydia,

Dann bestünde das Problem ja nur bei exakt 30em.

Und das ist genau eins zu viel. Damit hast Du nicht 3, sondern 4 Fälle, für die Du entwickeln und testen musst.

Das verstehe ich nun gar nicht mehr.

Mit und ohne

@media screen (max-width: 30em){}

gilt die schmale Definition solange width < 30em.

Richtig. Da die Regeln aber auch ohne die Definition @media screen (max-width: 30em) gilt, kannst und solltest du sie auch weglassen.

Ab 30em gilt ohne mein Vorschlag die schmale Definition (da keine Einschränkung) und es gilt die Definition für 30em.

Korrekt.

Ich muss also testen <30em, >=30em

Nein, musst du nicht. Sieh die Mediaqueries als Schalter für Ergänzungen zu den bereits vorhandenen Regeln, nicht als Schalter für (grundsätzliche) Ersetzungen.

Was will man den typischerweise für unterschiedlich große Viewports unterscheiden? Schriftart und -farbe sind es normalerweise nicht. Meist auch nicht Hintergrundfarben für bestimmte Bereiche (Seitenkopf, Navigation, Merksätze in Dokus, etc.). Normalerweise™️ verändert man Schriftgrößen, die Anordnung von Bereichen und Abstände.

Da man, um bei der obigen Auflistung zu bleiben, die Schriftarten und Farben bereits für schmale Viewports sowie Abstände festgelegt hat, und (die typischerweise) serielle Anordnung von Bereichen untereinander der Normalfall ist, für den man oft nicht einmal irgendwas festlegen muss, benutzt man die einen, allgemeingültigen Regeln einfach weiter und überschreibt und ergänzt für andere Anzeigegrößen und -medien nur jene Regeln, die gesondert behandelt gehören.

html {
  /* diese Regeln gelten immer */
  font-family: sans-serif;
  color: #013;
  font-size: 1em;
  font-size: 1rem;
}

body > * {
  /* die Regel für margin ist
   * nur für schmale Viewports gedacht
   */
  margin: 0.75em 0;
  padding: 0;
}

@media screen and (min-width: 32em) {
  body > * {
    /* der margin nach oben und unten wird
     * nun für breitere Viewports erhöht
     */
    margin: 1em 0;
  }
}

Das ist jetzt ein willkürliches Beispiel mit willkürlich notierten Regeln. Wie du siehst, überschreibe ich nur eine Regel, die bei breiteren Viewports (am 32em) einen größeren margin für direkte Kinder von body. In der Praxis wird man mehr und anderes überschreiben und ergänzen, aber als Beispiel für das Prinzip sollte es langen.

Tschö, Auge

[Lydia]

Hallo, ich erinnere an meinen Beitrag vom 30.03.2021 13:17.

Wenn der von Euch so vehement verteidigte Zustand optimal wäre, würde doch nicht jetzt die Variante

@media (30em <= width <= 50em ) im Gespräch und zum Teil schon realisiert.

Genau diese habe ich doch mit meinem Vorschlag mit der minimalen Fehlertoleranz nachvollzogen.
Ein frohes Osterfest wünscht Euch
Lydia

[Rolf B]

Hallo Lydia,

würde doch nicht jetzt die Variante @media (30em <= width <= 50em ) im Gespräch und zum Teil schon realisiert.

Könntest Du das bitte bequellen? Das kann keiner realisiert haben, weil es noch kein Browser unterstützt. Es sei denn, du jagst deine Würmer mit irgendwelchen besonders frühen Vögeln.

Und wenn sie funktioniert, ist sie - allein betrachtet - auch völlig problemlos. Die Probleme entstehen, wenn ein @media (width <= 30em) dazu kommt. Aber das erkläre ich nun schon zum drölften Mal

Rolf

[Lydia]

Eine der Quellen hat Jürgen bereits in seiner Antwort auf meinen ersten Beitrag genannt. Wenn man Hilfesuchende regelmäßig daran erinnert, dass etwas bereits erwähnt wurde oder man besser lesen sollte, so sollte dies auch für die Helfer gelten.
Dies sollte aber nicht verdecken, dass ich sehr dankbar bin auch für frühere Unterstützungen.

[Rolf B]

Hallo Lydia,

die Quellenanfrage bezog sich auf die Realisierung.

Und in der von Dir genannte Quelle MDN steht die Abfrage für sich allein, was, wie ich schon schrieb, unproblematisch ist. Abgesehen davon ist das lediglich ein Beispiel, das die Übertragung einer min-width and max-width Abfrage auf die neue Syntax belegt, und keine Diskussion über stacking vs not-stacking media queries.

Ich habe jetzt etwas geforscht, ob MDN überhaupt das Thema "mehrere Breakpoints und wie man es macht" anspricht, und, ja, tatsächlich 😜…

Rolf