@@Gunnar:

nuqneH

Das "funktioniert" halt nur so lange zuverlässig, wie die Annahme "Basis-Schriftgröße = 16px" zutrifft.

Eben.

Ebent! :-P

Denn das kann ja eigentlich nur zu "Problemen" führen, denn nicht nur bei Media Queries geht man als Autor von oben erwähnter Annahme bezüglich der Basis-Schriftgröße aus.

In anderen Fällen skaliert alles gleichermaßen, wenn konsequent em/rem verwendet werden (außer vielleicht für sowas wie border-width: 1px).

Letzteres sollte ja kein Problem darstellen.
Das andere gilt aber analog genauso für die Variante mit 'stacking mq'.

Und ein User müsste seine Basis-Schriftgröße auch so weit "ändern" (gehen wir mal von vergrößern aus), dass: 1 / Basis-Schriftgröße * 16 < 0.5

Also eine Basis-Schriftgröße > 32px!
Du darfst das gerne mal testen und mit so einer Einstellung durch's Netz surfen ...!

Ich hatte ja bereits gefragt:"Wer macht so etwas überhaupt, und wenn, warum?"

Ist eigentlich irgendwo festgelegt, dass die Basis-Schriftgröße 16px beträgt? Könnte ein Hersteller auf die Idee kommen, für sein Gerät 14px oder 18px zu wählen?

AFAIK ist das nicht festgelegt, und Apple weicht glaube ich auch bei einigen Geräten davon ab.

Aber das ist wie gesagt auch kein Problem, denn das Konstrukt ist ja nicht so fragil ..., es besteht ja durchaus einiger Spielraum, sowohl nach oben, als auch nach unten!

Andersherum muss ich ständig darauf achten, welche Eigenschaften gesetzt wurden und diese ggf. alle überschreiben.

Das "bläht" nicht nur den Code auf, sondern macht auch Änderungen wesentlich "unübersichtlicher".

Oder worin besteht deiner Meinung nach der Vorteil von 'overlapping mq'?
Außer dass du die eher theoretische Gefahr einer 1px großen Lücke in den MQ vermeidest.

Aber um deine Frage zu beantworten: Ich ziehe jeweils 1/16 von meinem nächsthöheren Breakpointwert ab.

Dann hast du eventuell eine Lücke bzw. Überschneidung. Nicht sehr wahrscheinlich, noch dazu dass die Viewportgröße beim Nutzer tatsächlich genau da rein fällt, aber dennoch möglich. Und als Entwickler möchte man möglichst robusten Code schreiben, der nicht bei Edge-Cases problematisch ist.

Abgesehen davon, dass wir das hier schon einige Male diskutiert haben, stufe ich das in die Kategorie "unvermeidbare Restrisiken" ein, die ich bereit bin, in Kauf zu nehmen.
Jedenfalls lieber als die Nachteile von 'overlapping mq'.

Außerdem hast du ja bereits selber mal (hier in einem Thread) festgestellt, dass das u.a. auf einen konzeptionellen Fehler im System der MQs zurückzuführen ist.

Und ferner würde sich dieses Problem auch dann erledigen, wenn die Browserhersteller die calc() Funktion mal entsprechend implementieren würden (was ich noch für am ehesten machbar halte). Denn wenn man

@media screen and (min-width: 20em) and (max-width: (30em - 1px)) { ... }  

dann hätte man das "Problem" auch nicht mehr.

Imho hat 'Mobile first' noch nie Sinn gemacht ...!
Da hat einer einen Hype ausgelöst, der zumindest für die allermeisten Projekte überhaupt keinen Vorteil bringt - eher das Gegenteil.

Denn alle (relevanten) Mobile Browser unterstützen Media Queries!
Das heißt, dass wenn ich "ältere" Browser ohne MQ Support unterstützen möchte, ich also eher ein Default brauche, der sich wie in Zeiten_vor_'Mobile first' an (älteren) Desktop Browsern 'orientiert'. Und hierbei hat sich seinerzeit eine fixe Breite von ~ 960px bestens bewährt.

Im übrigen sind ~960px auch wesentlich näher an DIN A4 dran, als bspw. 240px. Soll ja immer noch Leute geben, die auch ein Print Style brauchen/ haben wollen.

Ich wäre aber wirklich daran interessiert, von einem Anhänger des 'Mobile first' Ansatzes die Vorteile zu erfahren. Denn mit der einen Ausnahme, dass man aktuell 'stacking mq' in 'em' nicht 100%ig "wasserdicht" schreiben kann, sehe ich da keine.

Dann anders gefragt: Kennst du ein fertiges Mixin, welches automatisch die diversen Vendor Prefixes und 'resolution' erstellt, wenn ich eine device-ratio angebe?

Wo ist das Problem, sich das schnell selbst zu schreiben?

Kein Problem ...! ;-)
Mehr Interesse um zu sehen und zu lernen.

Gruß Gunther