nicht angemeldet
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
molily
molily
Gunnar Bittersmann
Gunnar Bittersmann
molily
molily
molily
Gunnar Bittersmann
Hallo werte Selfgemeinde!
Hier gibt es ja u.a. auch einige SASS-Experten, und an die habe ich folgende Frage:
Ich würde mir gerne meinen eigenen Mixin für @media rules schreiben.
Da dieser eine variable Anzahl an Parametern entgegennehmen soll, stehe ich aktuell vor dem Problem, dass ich die Verkettung der einzelnen Expressions per 'and' nicht hinbekomme.
Gibt es dafür eine Lösung (SASS >= 3.3), und wenn ja, wie sieht die aus?
Besten Dank im Voraus!
Gruß Gunther
@@Gunther:
nuqneH
Ich würde mir gerne meinen eigenen Mixin für @media rules schreiben.
Da dieser eine variable Anzahl an Parametern entgegennehmen soll, stehe ich aktuell vor dem Problem, dass ich die Verkettung der einzelnen Expressions per 'and' nicht hinbekomme.
Dein Mixin sieht dann wohl in etwa so aus?
@mixin mq($args...)
{
Zuerst baust du dir in einer Schleife den Query zusammen:
$query: "only screen";
@each $arg in $args
{
$query: $query + " and " + $arg;
}
Dann verwendest du den Query und bindest du den Content-Block ein:
@media #{$query}
{
@content;
}
}
Aufruf dann so:
body
{
@include mq("(min-width: 1em)", "(max-width: 2em)")
{
background: rebeccapurple;
}
}
Die Klammern könntest du natürlich auch mit dem Mixin generieren anstatt sie in den Argumenten zu haben.
Qapla'
PS: Die Forumsoftware erzählt mir, dass "scss" keine gültige Sprache für einen Code-Block sei. Dumme, die. ;-)
@@Gunnar:
nuqneH
Vielen Dank für deine Hilfe! :-)
Zuerst baust du dir in einer Schleife den Query zusammen:
$query: "only screen";
@each $arg in $args
{
$query: $query + " and " + $arg;
}
>
> Dann verwendest du den Query und bindest du den Content-Block ein:
>
> ~~~scss
@media #{$query}
> {
> @content;
> }
> }
>
Das hat fast auf Anhieb hingehauen ...,
einzig die quoted strings ("only screen" und " and ") musste ich jeweils noch in ein 'unquoted()' einschließen.
Die Klammern könntest du natürlich auch mit dem Mixin generieren anstatt sie in den Argumenten zu haben.
Werde ich mal testen.
Dank deiner freundlichen Unterstützung kann ich jetzt erstmal weiter basteln (u.a. möchte ich "benannte" Breakpoints verwenden können, die ich in einer Map speichere/ gespeichert sind).
Außerdem gehöre ich zu den Anhängern von 'stacked' MQs, d.h. ich verwende 'min-width' Werte für meine Breakpoints, und lasse die benötigten 'max-width' Werte in einer Funktion berechnen (natürlich alles in 'em's).
PS: Die Forumsoftware erzählt mir, dass "scss" keine gültige Sprache für einen Code-Block sei. Dumme, die. ;-)
Ja, sollte man mal ändern und ggf. auch mal überlegen, ob man 'SASS' nicht als eigenen Themenbereich einführt! ;-)
Für Tipps & Anregungen bin ich natürlich immer dankbar!
Gruß Gunther
PS: Hast du evt. auch noch einen Tipp bezüglich eines Mixins für 'resolution', bzw. 'min-device-pixel-ratio'?
@@Gunther:
nuqneH
Das hat fast auf Anhieb hingehauen ...,
einzig die quoted strings ("only screen" und " and ") musste ich jeweils noch in ein 'unquoted()' einschließen.
Hm, bei mir (Sass 3.3.7 auf Mac; sehe gerade, ich könnte mal updaten) läuft der Code wie gezeigt – auch ohne 'unquoted()'.
Außerdem gehöre ich zu den Anhängern von 'stacked' MQs, d.h. ich verwende 'min-width' Werte für meine Breakpoints, und lasse die benötigten 'max-width' Werte in einer Funktion berechnen (natürlich alles in 'em's).
Wie machst du das? Mit not? Oder wie umgehst du diese Problematik?
PS: Hast du evt. auch noch einen Tipp bezüglich eines Mixins für 'resolution', bzw. 'min-device-pixel-ratio'?
Mehr als dich auf die Tips für Fragende hinzuweisen lässt diese Frage jetzt aber nicht zu. ;-)
Qapla'
@@Gunther:
nuqneH
Das hat fast auf Anhieb hingehauen ...,
einzig die quoted strings ("only screen" und " and ") musste ich jeweils noch in ein 'unquoted()' einschließen.Hm, bei mir (Sass 3.3.7 auf Mac; sehe gerade, ich könnte mal updaten) läuft der Code wie gezeigt – auch ohne 'unquoted()'.
Bei mir (Windows + SASS 3.3.10) nicht.
Außerdem gehöre ich zu den Anhängern von 'stacked' MQs, d.h. ich verwende 'min-width' Werte für meine Breakpoints, und lasse die benötigten 'max-width' Werte in einer Funktion berechnen (natürlich alles in 'em's).
Wie machst du das? Mit
not? Oder wie umgehst du diese Problematik?
Ja, das ist halt der Haken an der Geschichte (overlapping mq haben aber imho ggf. mehr - kommt halt immer auf das jeweilige Projekt an).
Das "funktioniert" halt nur so lange zuverlässig, wie die Annahme "Basis-Schriftgröße = 16px" zutrifft.
Aber mal ehrlich: Ich habe mich schon des Öfteren gefragt, ob und wenn ja wer, seine Basis-Schriftgröße im Browser eigentlich "verstellt"?
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.
Und da erscheint mir die Zoom-Funktion der Browser doch das geeignetere Mittel der Wahl zu sein (zumal die Browser sich die jeweilige Zoom-Einstellung per Website "merken").
Imho ist die Option in den Browsern die Basis-Schriftgröße verändern zu können, ein "Schuss in den Ofen", bzw. ein "Griff ins Klo" gewesen!
Zumindest solange, wie der eingestellte Wert nicht per CSS "verwendet" werden kann.
Dazu müsste man aber erstmal so etwas wie "Umgebungsvariablen" in CSS einführen, deren Handhabung dann aber wiederum an der fehlenden (oder max. "rudimentären") Logik in CSS scheitert.
Solange also für das Layout relevante Einstellungen im Browser nicht berücksichtigt werden können, sollte man imho tunlichst die Finger davon lassen.
Aber um deine Frage zu beantworten: Ich ziehe jeweils 1/16 von meinem nächsthöheren Breakpointwert ab.
PS: Hast du evt. auch noch einen Tipp bezüglich eines Mixins für 'resolution', bzw. 'min-device-pixel-ratio'?
Mehr als dich auf die Tips für Fragende hinzuweisen lässt diese Frage jetzt aber nicht zu. ;-)
Ja, war etwas "knapp" formuliert ...! ;-)
Dann anders gefragt: Kennst du ein fertiges Mixin, welches automatisch die diversen Vendor Prefixes und 'resolution' erstellt, wenn ich eine device-ratio angebe?
Gruß Gunther
@@Gunnar:
nuqneH
Das hat fast auf Anhieb hingehauen ...,
einzig die quoted strings ("only screen" und " and ") musste ich jeweils noch in ein 'unquoted()' einschließen.Hm, bei mir (Sass 3.3.7 auf Mac; sehe gerade, ich könnte mal updaten) läuft der Code wie gezeigt – auch ohne 'unquoted()'.
Bei mir (Windows + SASS 3.3.10) nicht.
Hmmm ..., keine Ahnung (mehr), warum das eben nicht funktioniert hat, aber ich habe es jetzt nochmal ohne 'unquote()' ausprobiert, und siehe da - es funktioniert!
Gruß Gunther
@@Gunther:
nuqneH
Das "funktioniert" halt nur so lange zuverlässig, wie die Annahme "Basis-Schriftgröße = 16px" zutrifft.
Eben.
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).
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?
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.
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?
@mixin resmq($dppx)
{
@media
(-webkit-min-device-pixel-ratio: $dppx),
(min-resolution: #{$dppx * 96}dpi),
(min-resolution: #{$dppx}dppx)
{
@content;
}
}
Aufruf:
body
{
@include resmq(2)
{
@include mq("(min-width: 1em)", "(max-width: 2em)")
{
background: rebeccapurple;
}
}
}
oder
body
{
@include mq("(min-width: 1em)", "(max-width: 2em)")
{
@include resmq(2)
{
background: rebeccapurple;
}
}
}
Sass sortiert sich das schon. Ist ja nicht LESS.
Qapla'
@@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
@@Gunther:
nuqneH
Oder worin besteht deiner Meinung nach der Vorteil von 'overlapping mq'?
Es entspricht dem Progressive-enhancement-Gedanken: Bessere Geräte bekommen bessere Features. Besser heißt hier größer und Feature Ansicht.
Basisansicht für alle („mobile first“); größerer Viewport → Breakpoint, der die Ansicht aufwertet – mit _zusätzlichen_ Style-Regeln. Noch größerer Viewport → Breakpoint, der die Ansicht noch mehr aufwertet – mit weiteren _zusätzlichen_ Style-Regeln.
Imho hat 'Mobile first' noch nie Sinn gemacht ...!
IMHO macht das schon Sinn. Wonei sich der Gedanke nicht nur aufs Layout bezieht, sondern viel früher ansetzt: Inhaltsmanagement, Informationsarchitektur, … Nicht zu vergessen: Bandbreite und Performance.
Erstmal Beschränkung aufs Wesentliche, und wenn man mehr Platz zum Anzeigen hat, sollte man überlegen, ob zusätzliche Inhalt es wirklich wert sind angezeigt zu weredn oder ob sie nur den Bildschirm zumüllen.
Bei „desktop first“ fängt man mit viel Müll an und es fällt schwer, sich davon zu trennen.
In vielen Fällen ist mit „mobile first“ progressive enhancement gemeint. Was auch nicht heißen muss, dass man auf Mobilgeräten weniger hat. Schließlich haben Mobilgeräte Bewegungssensoren, GeoLocation u.a., mit denen Features hinzugefügt werden können, die bei Desktopgeräten nicht verfügbar sind.
Da hat einer einen Hype ausgelöst, der zumindest für die allermeisten Projekte überhaupt keinen Vorteil bringt - eher das Gegenteil.
Das kann daran liegen, dass die Projekte nicht richtig geplant worden sind. Dass bspw. der Mobile-first-Gedanke nur aufs Layout bezogen wurde.
Und hierbei hat sich seinerzeit eine fixe Breite von ~ 960px bestens bewährt.
Als ich noch einen Monitor mit 640 oder 800 px Breite hatte, war ich von solchen Webseiten recht begeistert. Nicht.
Gerätespezifische Darstellungsangaben waren noch nie gut fürs Web. Responsive Design bringt die (dem Web inhärente!) Flexibilität zurück, die jahrelang versaut wurde.
Qapla'
@@Gunnar:
nuqneH
Oder worin besteht deiner Meinung nach der Vorteil von 'overlapping mq'?
Es entspricht dem Progressive-enhancement-Gedanken: Bessere Geräte bekommen bessere Features. Besser heißt hier größer und Feature Ansicht.
Also sagst du: Progressive Enhancement = overlapping MQs
Bezeichnenderweise steht in der Definition des Englischen Wikipedia Artikels gar nichts von "Bildschirm-/ Viewportgröße".
[Zitat]
Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth. (Quelle: http://en.wikipedia.org/wiki/Progressive_enhancement)
[/Zitat]
Basisansicht für alle („mobile first“); größerer Viewport → Breakpoint, der die Ansicht aufwertet – mit _zusätzlichen_ Style-Regeln. Noch größerer Viewport → Breakpoint, der die Ansicht noch mehr aufwertet – mit weiteren _zusätzlichen_ Style-Regeln.
Und genau hier sehe ich einen der "Knackpunkte" des "Mobile First" Ansatzes.
Basisansicht für alle ...
Warum sollte sich eine/ die Basisansicht denn bitte ausgerechnet am KAV (kleinster anzunehmender Viewport) orientieren!?
Zumal heutzutage alle relevanten Mobile Browser MQ unterstützen.
Ergo dürften Browser, die eine "Basisansicht" brauchen, nicht unbedingt auf Geräten mit einem sehr kleinen Viewport anzutreffen sein.
Außerdem bezog und bezieht sich imho progressive enhancement, genauso wie graceful degradation, immer auf den verwendeten Browser und dessen Fähigkeiten - nicht auf die Größe eines verwendeten Displays/ Monitor.
Imho hat 'Mobile first' noch nie Sinn gemacht ...!
IMHO macht das schon Sinn. Wonei sich der Gedanke nicht nur aufs Layout bezieht, sondern viel früher ansetzt: Inhaltsmanagement, Informationsarchitektur, … Nicht zu vergessen: Bandbreite und Performance.
Das ist sicher alles richtig und ich gehe da auch mit dir d'accord. Nur hat das für mich nichts mit "Mobile first" zu tun.
Denn wenn eine Website nachher zwar die "optimale" Benutzbarkeit für kleine Viewports bietet, dafür aber auf Bildschirmen mit Full HD Auflösung "schei... aussieht" (als Sammelbegriff für schlechte Bedienbarkeit, fehlende Übersicht etc.), dann ist das Endresultat genauso misslungen.
Denn normalerweise geht man doch von vorhandenen Inhalten aus, und muss sich überlegen, wie man diese jeweils bestmöglich auf unterschiedlichen Viewports darstellen kann.
Womit ich da bei den Überlegungen anfange, macht für mich keinen Unterschied.
Denn bevor man mit dem Erstellen anfängt, sollte man die Planung für alle Viewportgrößen abgeschlossen haben.
Erstmal Beschränkung aufs Wesentliche, und wenn man mehr Platz zum Anzeigen hat, sollte man überlegen, ob zusätzliche Inhalt es wirklich wert sind angezeigt zu weredn oder ob sie nur den Bildschirm zumüllen.
Auch hier neige ich zu einer leicht anderen Betrachtungsweise:
Grob gesagt, wenn man ganz radikal kategorisieren möchte, gibt es nur 2 Kategorien, nämlich
1. relevante Inhalte
2. nicht relevante Inhalte
Inhalte, die zur Kategorie 1 zählen, müssen (sollten) jeweils immer angezeigt werden.
Inhalte der Kategorie 2 sind zwar nicht zwingend für den reinen Informationsgehalt der Seite notwendig, liefern dem User aber ggf. eine bessere Übersicht und/ oder zusätzliche Informationen.
Diese kann man dann eben vom vorhandenen Platzangebot abhängig machen.
Und wieder braucht es keinen "Mobile first" Ansatz ...!
Bei „desktop first“ fängt man mit viel Müll an und es fällt schwer, sich davon zu trennen.
In vielen Fällen ist mit „mobile first“ progressive enhancement gemeint. Was auch nicht heißen muss, dass man auf Mobilgeräten weniger hat. Schließlich haben Mobilgeräte Bewegungssensoren, GeoLocation u.a., mit denen Features hinzugefügt werden können, die bei Desktopgeräten nicht verfügbar sind.
Genau!
Und hier sind wir im Bereich der "geräteabhängigen Möglichkeiten".
Auch das hat imho nichts mit "Mobile first" zu tun.
Deine oben genannten Features finden sich ja bspw. auf Smartphones genauso wie auf Tablets, deren jeweilige Viewportgrößen sich teils ganz gewaltig voneinander unterscheiden!
Da hat einer einen Hype ausgelöst, der zumindest für die allermeisten Projekte überhaupt keinen Vorteil bringt - eher das Gegenteil.
Das kann daran liegen, dass die Projekte nicht richtig geplant worden sind. Dass bspw. der Mobile-first-Gedanke nur aufs Layout bezogen wurde.
Das mag vielleicht zutreffen - spielt aber letzendlich keine Rolle.
Denn wenn ich unter einem Begriff/ Konzept wie "Mobile first" so ungefähr "alles" verstehen kann, oder jeder etwas anderes darunter versteht, wozu ist es dann noch gut?
Und für mich ist bis heute zumindest ein wesentlicher Bestandteil von "Mobile first" der, dass man sein CSS so aufbaut, dass man (ohne MQ) beim KAV anfängt und dann per 'overlapping' MQs mit 'min-width' für immer größer werdende Viewports erweitert.
Und genau dieses "Konzept" stelle ich zumindest für viele Sites in Frage!
Und hierbei hat sich seinerzeit eine fixe Breite von ~ 960px bestens bewährt.
Als ich noch einen Monitor mit 640 oder 800 px Breite hatte, war ich von solchen Webseiten recht begeistert. Nicht.
Du weißt selber ganz genau, dass sich sowohl die zur Verfügung stehenden Techniken, als auch die "relevante" Hardware seither ständig weiterentwickelt haben.
Gerätespezifische Darstellungsangaben waren noch nie gut fürs Web. Responsive Design bringt die (dem Web inhärente!) Flexibilität zurück, die jahrelang versaut wurde.
Das ist doch reine Definitionssache.
Oder sind 'min-/max-width' MQs für dich keine "gerätespezifischen Darstellungsangaben"!?
Nochmal:
Was mich im Grunde genommen stört ist, dass per "Mobile first" Slogan im Bezug auf das CSS eine Methode favorisiert wird, die imho vielleicht vor 3-4 Jahren "sinnvoll" gewesen sein mag, die heutzutage aber für die allermeisten Projekte eher von Nachteil, denn von Vorteil ist!
Und auch du bist hier im Prinzip nicht auf die Unterschiede (Vor- & Nachteile) der beiden unterschiedlichen Strategien ('overlapping' <-> 'stacking') eingegangen!
Wenn man diese nämlich mal konkret nebeneinander stellen würde, dann bin ich ziemlich davon überzeugt, dass sie sich mindestens die Waage halten! Es demnach also keinen (vernünftigen) Grund gibt, automatisch eines der Konzepte dem anderen gegenüber vorzuziehen!
Alles andere, was du hier genannt und aufgeführt hast, fällt für mich unter den Oberbegriff "RWD" und hat nichts mit "Mobile first" zu tun!
Gruß Gunther
@@Gunther:
nuqneH
Bezeichnenderweise steht in der Definition des Englischen Wikipedia Artikels gar nichts von "Bildschirm-/ Viewportgröße".
Warum sollten auch deutsche Begriffe in einem englischen Wikipedia-Artikel stehen? ;-b
Basisansicht für alle ...
Warum sollte sich eine/ die Basisansicht denn bitte ausgerechnet am KAV (kleinster anzunehmender Viewport) orientieren!?
Weil nach unten kein enhancement möglich ist, sondern nur degration.
Außerdem bezog und bezieht sich imho progressive enhancement, genauso wie graceful degradation, immer auf den verwendeten Browser und dessen Fähigkeiten - nicht auf die Größe eines verwendeten Displays/ Monitor.
Nö. Aufs ganze System. Browser, Display, Netzwerkanbindung, Sensoren, …
Denn wenn eine Website nachher zwar die "optimale" Benutzbarkeit für kleine Viewports bietet, dafür aber auf Bildschirmen mit Full HD Auflösung "schei... aussieht" (als Sammelbegriff für schlechte Bedienbarkeit, fehlende Übersicht etc.), dann ist das Endresultat genauso misslungen.
Ja. Dann wurde nicht genügend enhancet. (Man verzeihe mir das Denglisch.)
Denn normalerweise geht man doch von vorhandenen Inhalten aus, und muss sich überlegen, wie man diese jeweils bestmöglich auf unterschiedlichen Viewports darstellen kann.
Das ist eine Designentscheidung. Ob man das technisch mit stacked MQs oder overlapping MQs umsetzt, ist eine Architekturentscheidung.
Denn bevor man mit dem Erstellen anfängt, sollte man die Planung für alle Viewportgrößen abgeschlossen haben.
Nei-en!!! Wasserfall, pfui bäh!
Im Idelfall sitzen Designer und Entwickler und entwickeln gemeinsam im Browser. So hat man kurze Wege bei iterativer Entwicklung. (gefunden bei meinem geschätzten Kollegen)
In vielen Fällen ist mit „mobile first“ progressive enhancement gemeint.
Auch das hat imho nichts mit "Mobile first" zu tun.
Sag ich doch.
Du weißt selber ganz genau, dass sich sowohl die zur Verfügung stehenden Techniken, als auch die "relevante" Hardware seither ständig weiterentwickelt haben.
Das heißt aber noch lange nicht, dass alle Nutzer auf neusten Stand sind.
Gerätespezifische Darstellungsangaben waren noch nie gut fürs Web. Responsive Design bringt die (dem Web inhärente!) Flexibilität zurück, die jahrelang versaut wurde.
Oder sind 'min-/max-width' MQs für dich keine "gerätespezifischen Darstellungsangaben"!?
Zum einen hab ich mich da ungenau ausgedrückt. Gemeint waren bspw. Seiten mit fixen Breiten (960px), die sich nicht an Ausgabegeräte anpassen.
Zum anderen sollten sich Breakpoints am Inhalt, nicht an gerade gängigen Geräten orientieren.
Was mich im Grunde genommen stört ist, dass per "Mobile first" Slogan im Bezug auf das CSS eine Methode favorisiert wird, die imho vielleicht vor 3-4 Jahren "sinnvoll" gewesen sein mag, die heutzutage aber für die allermeisten Projekte eher von Nachteil, denn von Vorteil ist!
YMMV.
Und auch du bist hier im Prinzip nicht auf die Unterschiede (Vor- & Nachteile) der beiden unterschiedlichen Strategien ('overlapping' <-> 'stacking') eingegangen!
Das taten andere.
Qapla'
@@Gunnar Bittersmann:
nuqneH
Im Idelfall sitzen Designer und Entwickler und entwickeln gemeinsam im Browser.
Die beiden sollten natürlich nicht (ein)sitzen, sondern zusammensitzen — freiwillig.
Qapla'
@@Gunnar:
nuqneH
Ich kürze das hier mal ab. Vieles habe ich in der Antwort auf Mathias Post ja bereits geschrieben.
Auf die Geschichte mit dem "Workflow" möchte ich gar nicht weiter eingehen, denn ist ein eigenständiges Kapitel, das mit dem Punkt, um den es mir hier geht, nicht direkt etwas zu tun hat.
Und es macht sicherlich auch einen Unterschied, ob es sich um eine "Mehr-User" oder "Einzel-User" Abteilung handelt.
Und auch du bist hier im Prinzip nicht auf die Unterschiede (Vor- & Nachteile) der beiden unterschiedlichen Strategien ('overlapping' <-> 'stacking') eingegangen!
Das taten andere.
Sorry, aber der Artikel ist mit Verlaub "für die Tonne".
Ich kannte den Artikel auch schon, weil er (leider), wenn man nach "overlapping vs. stacking" sucht, meist mit ganz oben auftaucht.
Die Auflistung der "Pros and Cons" ist bestenfalls als "unvollständig" zu bezeichnen.
Die "Schlussfolgerung/ Entscheidung" basiert mehr auf "Bauchgefühl" und "Annahmen", als dass sie objektiv untermauert wäre.
Abschließend möchte ich mal kurz zusammenfassen:
Wie alleine schon unsere Diskussion hier gezeigt hat, scheint es in der Praxis keine einheitliche Vorstellung davon zu geben, was genau denn nun eigentlich unter "Mobile first" zu verstehen ist.
Das alleine macht die Verwendung dieses Begriffs schon "problematisch".
Wie viele Beiträge im Netz zeigen, verstehen viele/ einige darunter aber zumindest auch immer den Aufbau des CSS Layouts per 'overlapping MQs'.
Diese Vorgehensweise kann keinesfalls "pauschal" immer als die Beste angesehen werden. Vielmehr sollte man im jeweiligen Einzelfall entscheiden!
Auch ob bei der "Planung" immer vom KAV (kleinsten anzunehmenden Viewport) ausgegangen werden sollte, darf man zumindest in Frage stellen, wenn nicht gar verneinen!
Progressive enhancement so zu interpretieren, dass man größere Viewports als "enhancement" ansieht, kann man machen, muss man aber nicht.
Monochrome/ Farbe und Display Auflösung fallen z.B. für mich darunter. Die Viewportgröße nicht, denn auf vielen Geräten ist diese u.a. ja auch veränderbar.
Progressive enhancement ist für mich ein eigenständiger Punkt/ Aspekt (den man immer berücksichtigen sollte), der nicht zwingend mit "Mobile first" verbunden ist. Vielmehr ist er_auch_ein Bestandteil von "Mobile first".
Wenn ich mir diese drei Punkte angucke, dann stellt sich mir die Frage, ob "Mobile first" wirklich so ein "gelungenes Konzept" (oder als was man das auch immer bezeichnen will) ist!?
Es geht doch in der Praxis nicht um "Mobile first" vs. "Desktop first". Allenfalls um "Content & User Experience (first)". Wobei ich das Wort "first" in allen Fällen "unschön" finde, da es im Prinzip immer um eine Site als Ganzes geht - aber mit irgendetwas muss man ja anfangen.
Gruß Gunther
Hallo!
Ergo dürften Browser, die eine "Basisansicht" brauchen, nicht unbedingt auf Geräten mit einem sehr kleinen Viewport anzutreffen sein.
Welche Browser brauchen denn deiner Meinung nach eine Basisansicht? Meinst du Dinosaurier wie IE 6?
Außerdem bezog und bezieht sich imho progressive enhancement, genauso wie graceful degradation, immer auf den verwendeten Browser und dessen Fähigkeiten - nicht auf die Größe eines verwendeten Displays/ Monitor.
Progressive Enhancement bezieht sich auf alle technischen Gegebenheiten und Fähigkeiten. Natürlich auch den Viewport. Größerer Viewport == ich habe mehr Raum, Inhalte darzustellen, mehr Möglichkeiten, Inhalte zu layouten.
Wonei sich der Gedanke nicht nur aufs Layout bezieht, sondern viel früher ansetzt: Inhaltsmanagement, Informationsarchitektur, … Nicht zu vergessen: Bandbreite und Performance.
Das ist sicher alles richtig und ich gehe da auch mit dir d'accord. Nur hat das für mich nichts mit "Mobile first" zu tun.
Was Gunnar schildert, *ist* die gängige Definition von Mobile First.
Denn wenn eine Website nachher zwar die "optimale" Benutzbarkeit für kleine Viewports bietet, dafür aber auf Bildschirmen mit Full HD Auflösung "schei... aussieht" (als Sammelbegriff für schlechte Bedienbarkeit, fehlende Übersicht etc.), dann ist das Endresultat genauso misslungen.
Ja, klar. Fragt sich allerdings, ob das Hinzufügen von noch mehr Inhalt und Funktionen auf großen Viewports die Site unbedingt besser macht (Gunnar hatte es angesprochen).
- relevante Inhalte
- nicht relevante Inhalte
(…) Diese kann man dann eben vom vorhandenen Platzangebot abhängig machen.
Ja, sicher, das ist nicht ausgeschlossen. Dafür gibt es verschiedene Techniken. Z.B. das Unterbringen der Inhalte im HTML und Verstecken/Zusammendampfen auf kleinen Viewports, oder das Nachladen von Inhalten auf großen Viewports.
Und wieder braucht es keinen "Mobile first" Ansatz ...!
Du scheinst das Konzept misszuverstehen. »Mobile First« trägt der Tatsache Rechnung trägt, dass Mobilgeräte bald die vorherrschenden Web-Zugangsgeräte sein werden. Man bräuchte ihn nicht, wenn die Webindustrie schon immer funktionierende Produkte für alle relevanten Zugänge herausgebracht hätte. Das ist nicht der Fall, vielmehr herrscht immer noch ein starres »Desktop First«, das uns immer noch überladene Sites mit Flash-Plugins und Hinweisen wie »Bitte benutzen sie einen Desktop-Browser, damit sie die Site vollwertig nutzen können« bringt. »Mobile First« versucht das in erster Linie konzeptionell, in zweiter Linie hinsichtlich UI-/UX-Design, in dritter Linie technisch aufzusprengen.
Denn wenn ich unter einem Begriff/ Konzept wie "Mobile first" so ungefähr "alles" verstehen kann
Es gibt Artikel/Bücher, die das Konzept sauber definieren und die auch den Begriff geprägt haben:
http://www.lukew.com/
http://bradfrostweb.com/
Und für mich ist bis heute zumindest ein wesentlicher Bestandteil von "Mobile first" der, dass man sein CSS so aufbaut, dass man (ohne MQ) beim KAV anfängt und dann per 'overlapping' MQs mit 'min-width' für immer größer werdende Viewports erweitert.
Diese Vorgehensweise ist am verbreitesten, würde ich vermuten. Als »wesentlich« würde ich das nicht bezeichnen, weil es bei »Mobile First« nicht um einzelne CSS-Techniken geht, sondern um ein größeres Design- und Technik-Konzept.
Übrigens glaube ich nicht, dass es größere responsive Sites gibt, die streng *nur* overlapping MQs verwenden. Warum sollte man sich darauf beschränken? Ich habe schon das Gridsystem von Bootstrap verlinkt. Dort werden üblicherweise overlapping MQs verwendet, aber es gibt genauso Klassen und Helfer zum Generieren von stacked MQs. Zurb Foundation arbeitet genauso.
Ich entscheide das einmal für die Site, aber immer wieder im Einzelfall: Wenn das Interface für kleine Viewports komplett anders aussieht als das für große, ergibt es wenig Sinn, dutzende Regeln für größere Viewports wieder rückgängig zu machen. Dazu müsste ich eine Menge an Code schreiben, der von anderem Code abhängt und immer mitgewartet werden will.
Also arbeite ich an dieser Stelle mit stacked MQs, selbst wenn die Site allgemein mit overlapping MQs arbeitet. In meinem Sass-Werkzeugkasten habe ich Mixins für beides.
Was mich im Grunde genommen stört ist, dass per "Mobile first" Slogan im Bezug auf das CSS eine Methode favorisiert wird, die imho vielleicht vor 3-4 Jahren "sinnvoll" gewesen sein mag, die heutzutage aber für die allermeisten Projekte eher von Nachteil, denn von Vorteil ist!
Das halte ich für falsch. Was sind denn die »allermeisten« Projekte, bei denen das von Nachteil ist?
Bei textlastigen Sites ist es kein Problem, dass die meisten Styles für alle Viewport-Größen gelten. Es ist keine scharfe Trennung zwischen verschiedenen Viewport-Größen nötig, wie es stacked MQs tun.
Auszug aus Gunnars Link:
»Most sites don’t have radically different looks between media queries—sure, the layout might appear very different, but things like the typography, colors, and various visual effects are usually the same.«
Es demnach also keinen (vernünftigen) Grund gibt, automatisch eines der Konzepte dem anderen gegenüber vorzuziehen!
Doch. Overlapping MQs haben den eingebauten Vorteil, dass Code per default wiederverwendet wird. Das ist eine gute Sache, daraufhin sollte man CSS optimieren.
Viel Grüße
Mathias
@@molily:
nuqneH
»Bitte benutzen sie einen Desktop-Browser, damit sie die Site vollwertig nutzen können«
Hab ich grad ein Déjà-vu?
Und weiterlesen, “It's a new world coming” ;-)
Qapla'
Hallo Mathias!
Es freut mich, dass du dich an der Diskussion beteiligst. :-)
Ergo dürften Browser, die eine "Basisansicht" brauchen, nicht unbedingt auf Geräten mit einem sehr kleinen Viewport anzutreffen sein.
Welche Browser brauchen denn deiner Meinung nach eine Basisansicht? Meinst du Dinosaurier wie IE 6?
Meiner Meinung nach heutzutage eigentlich kein Browser mehr, da alle MQs unterstützen.
Von daher hätte ich besser den Konjunktiv verwendet, und 'bräuchten' geschrieben.
Ich habe das auch nur aus dem Grund angeführt, weil Gunnar die "Basisansicht für alle" erwähnt hatte.
Außerdem bezog und bezieht sich imho progressive enhancement, genauso wie graceful degradation, immer auf den verwendeten Browser und dessen Fähigkeiten - nicht auf die Größe eines verwendeten Displays/ Monitor.
Progressive Enhancement bezieht sich auf alle technischen Gegebenheiten und Fähigkeiten. Natürlich auch den Viewport. Größerer Viewport == ich habe mehr Raum, Inhalte darzustellen, mehr Möglichkeiten, Inhalte zu layouten.
Das ist mir völlig neu, und ich halte das auch für eine "nicht hilfreiche" Ausdehnung/ -weitung des Begriffs.
Und warst/ bist du nicht einer derjenigen, die hier schon öfter geschrieben haben, dass es praktisch nicht möglich ist, etwas über den jeweils verwendeten Internetzugang "zu wissen"!?
Wonei sich der Gedanke nicht nur aufs Layout bezieht, sondern viel früher ansetzt: Inhaltsmanagement, Informationsarchitektur, … Nicht zu vergessen: Bandbreite und Performance.
Das ist sicher alles richtig und ich gehe da auch mit dir d'accord. Nur hat das für mich nichts mit "Mobile first" zu tun.
Was Gunnar schildert, *ist* die gängige Definition von Mobile First.
Sorry, aber das gehört imho alles zu dem (Ober)Begriff "Responsive Web Design", aber nicht alles zu "Mobile first".
Mobile first, unobtrusive JavaScript, und progressive enhancement kann man heutzutage sicher alle zu "RWD" zählen. Aber die beiden letztgenannten zu Mobile first zu zählen, halte ich dann doch für falsch.
Denn wenn eine Website nachher zwar die "optimale" Benutzbarkeit für kleine Viewports bietet, dafür aber auf Bildschirmen mit Full HD Auflösung "schei... aussieht" (als Sammelbegriff für schlechte Bedienbarkeit, fehlende Übersicht etc.), dann ist das Endresultat genauso misslungen.
Ja, klar. Fragt sich allerdings, ob das Hinzufügen von noch mehr Inhalt und Funktionen auf großen Viewports die Site unbedingt besser macht (Gunnar hatte es angesprochen).
Das ist ja kein Muss, sondern eine Option, die nur dann gewählt werden sollte, wenn sie diese Bedingung erfüllt.
- relevante Inhalte
- nicht relevante Inhalte
(…) Diese kann man dann eben vom vorhandenen Platzangebot abhängig machen.Ja, sicher, das ist nicht ausgeschlossen. Dafür gibt es verschiedene Techniken. Z.B. das Unterbringen der Inhalte im HTML und Verstecken/Zusammendampfen auf kleinen Viewports, oder das Nachladen von Inhalten auf großen Viewports.
Und wieder braucht es keinen "Mobile first" Ansatz ...!
Du scheinst das Konzept misszuverstehen. »Mobile First« trägt der Tatsache Rechnung trägt, dass Mobilgeräte bald die vorherrschenden Web-Zugangsgeräte sein werden. Man bräuchte ihn nicht, wenn die Webindustrie schon immer funktionierende Produkte für alle relevanten Zugänge herausgebracht hätte. Das ist nicht der Fall, vielmehr herrscht immer noch ein starres »Desktop First«, das uns immer noch überladene Sites mit Flash-Plugins und Hinweisen wie »Bitte benutzen sie einen Desktop-Browser, damit sie die Site vollwertig nutzen können« bringt. »Mobile First« versucht das in erster Linie konzeptionell, in zweiter Linie hinsichtlich UI-/UX-Design, in dritter Linie technisch aufzusprengen.
Nein, von solchen Seiten rede ich gar nicht. Ich habe hier schon einen "RWD" Ansatz vorausgesetzt.
Und mir geht es im Prinzip auch rein um "Mobile first".
Denn wenn ich unter einem Begriff/ Konzept wie "Mobile first" so ungefähr "alles" verstehen kann
Es gibt Artikel/Bücher, die das Konzept sauber definieren und die auch den Begriff geprägt haben:
http://www.lukew.com/
http://bradfrostweb.com/Und für mich ist bis heute zumindest ein wesentlicher Bestandteil von "Mobile first" der, dass man sein CSS so aufbaut, dass man (ohne MQ) beim KAV anfängt und dann per 'overlapping' MQs mit 'min-width' für immer größer werdende Viewports erweitert.
Diese Vorgehensweise ist am verbreitesten, würde ich vermuten. Als »wesentlich« würde ich das nicht bezeichnen, weil es bei »Mobile First« nicht um einzelne CSS-Techniken geht, sondern um ein größeres Design- und Technik-Konzept.
Und mein Eindruck ist der, dass (sehr) viele aber genau das unter "Mobile first" verstehen.
Dazu braucht man sich ja nur mal Googles Ergebnisse für "Mobile first" anzugucken.
Und hier mal exemplarisch 2 Links:
1. http://blog.kulturbanause.de/2013/08/mobile-first-progressive-enhancement/
2. http://radar.oreilly.com/2013/06/mobile-first-not-so-fast.html?utm_content=buffer4dfe3&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer
Der erste "verdeutlicht" dann wohl das "allgemein vorherrschende Missverständnis".
Der zweite zeigt, dass es auch andere Menschen gibt, die ein ähnliches "Problem" mit "Mobile first" haben, wie ich.
Übrigens glaube ich nicht, dass es größere responsive Sites gibt, die streng *nur* overlapping MQs verwenden. Warum sollte man sich darauf beschränken?
Eben!
Ich habe schon das Gridsystem von Bootstrap verlinkt. Dort werden üblicherweise overlapping MQs verwendet, aber es gibt genauso Klassen und Helfer zum Generieren von stacked MQs. Zurb Foundation arbeitet genauso.
Ich entscheide das einmal für die Site, aber immer wieder im Einzelfall:
Das ist doch genau einer der Punkte, um die es mir geht. Anstatt zu propagieren, dass man pauschal immer den "Mobile first" Ansatz mit seinen overlapping MQs (min-width) verwendet, sollte man diese Entscheidung vom Einzelfall abhängig machen.
Wenn das Interface für kleine Viewports komplett anders aussieht als das für große, ergibt es wenig Sinn, dutzende Regeln für größere Viewports wieder rückgängig zu machen. Dazu müsste ich eine Menge an Code schreiben, der von anderem Code abhängt und immer mitgewartet werden will.
FACK
Also arbeite ich an dieser Stelle mit stacked MQs, selbst wenn die Site allgemein mit overlapping MQs arbeitet. In meinem Sass-Werkzeugkasten habe ich Mixins für beides.
Overlapping MQs haben imho einen wesentlichen Nachteil, und zwar dass es bei Ihnen auf die Reihenfolge im CSS ankommt!
Das birgt etliche "Gefahren" und macht den Code alles andere als "robust" (wie Gunnar das so gerne formuliert).
Was mich im Grunde genommen stört ist, dass per "Mobile first" Slogan im Bezug auf das CSS eine Methode favorisiert wird, die imho vielleicht vor 3-4 Jahren "sinnvoll" gewesen sein mag, die heutzutage aber für die allermeisten Projekte eher von Nachteil, denn von Vorteil ist!
Das halte ich für falsch. Was sind denn die »allermeisten« Projekte, bei denen das von Nachteil ist?
Bei textlastigen Sites ist es kein Problem, dass die meisten Styles für alle Viewport-Größen gelten. Es ist keine scharfe Trennung zwischen verschiedenen Viewport-Größen nötig, wie es stacked MQs tun.
Und imho handelt es sich bei den »allermeisten« Sites eben genau nicht um solche textlastigen Sites.
Aber lassen wir das einfach mal dahingestellt sein, denn es geht ja eigentlich nur darum, dass wie oben erwähnt, man von Fall zu Fall (Einzelfallentscheidung) entscheiden sollte, und nicht "blind" einfach irgendeinem "Slogan" folgt.
Auszug aus Gunnars Link:
»Most sites don’t have radically different looks between media queries—sure, the layout might appear very different, but things like the typography, colors, and various visual effects are usually the same.«
Das ist doch kein Argument gegen 'stacking MQs'. Hier kann ich ja genauso meine Typografie und andere Dinge 'sitewide' und/ oder 'overlapping' festlegen!
Es demnach also keinen (vernünftigen) Grund gibt, automatisch eines der Konzepte dem anderen gegenüber vorzuziehen!
Doch. Overlapping MQs haben den eingebauten Vorteil, dass Code per default wiederverwendet wird. Das ist eine gute Sache, daraufhin sollte man CSS optimieren.
Und die eingebauten Nachteile, dass es u.a.
Was man vielleicht auch nicht vergessen sollte ist, dass es ja nicht nur "Professionals" gibt. Und ich behaupte einfach mal, dass 'overlapping MQs' für "Laien" wesentlich "unübersichtlicher" und somit nachteiliger sind!
Und selbst wenn dann nachher bei ~ 2.000 Zeilen CSS Code (unkomprimiert) 50 Zeilen mehr Code dabei herauskommen - na und?
Das ist hinterher bei der 'gzip' Auslieferung des Codes so was von ...! ;-)
Gruß Gunther
Hallo,
Progressive Enhancement bezieht sich auf alle technischen Gegebenheiten und Fähigkeiten. Natürlich auch den Viewport. Größerer Viewport == ich habe mehr Raum, Inhalte darzustellen, mehr Möglichkeiten, Inhalte zu layouten.
Das ist mir völlig neu, und ich halte das auch für eine "nicht hilfreiche" Ausdehnung/ -weitung des Begriffs.
Was ist daran eine Ausweitung? Das war schon immer die Bedeutung des Begriffs.
Und warst/ bist du nicht einer derjenigen, die hier schon öfter geschrieben haben, dass es praktisch nicht möglich ist, etwas über den jeweils verwendeten Internetzugang "zu wissen"!?
Ja, und? Es gibt genug Parameter, die ich bereits ohne Probleme ins Progressive Enhancement einbeziehen kann. Dass etwas momentan nicht praktisch möglich, ist schließt nicht aus, dass es irgendwann einmal einfach möglich ist. Dass ein Parameter existiert, z.B. der verwendete Internetzugang, heißt nicht zwangsläufig, dass ich die Seite daraufhin anpasse. Wichtig ist, dass man sich nicht verzettelt und sehr genau auswählt, nach welchen Umgebungsbedingungen unterschieden wird.
Anstatt zu propagieren, dass man pauschal immer den "Mobile first" Ansatz mit seinen overlapping MQs (min-width) verwendet, …
Himmel, wer tut das denn bitte?! Niemand!
Auf die Gefahr hin, mich zu wiederholen: »Mobile First« hat mit konkreten CSS-Techniken wenig zu tun. Wenn du mir auch nur eine einflussreiche Quelle nennst, die Mobile First *notwendig* mit overlapping MQs zusammenbringt und stacked *kategorisch ausschließt*, würde ich vielleicht verstehen, warum du hier so gegen Mobile First und overlapping MQs wetterst. Ich denke nicht, dass du eine finden wirst, sondern dass ein Missverständnis deinerseits vorliegt.
Overlapping MQs haben imho einen wesentlichen Nachteil, und zwar dass es bei Ihnen auf die Reihenfolge im CSS ankommt!
Ja, das tut es. Aber ist das ein praktisches Problem oder nur ein theoretisches? Ich habe diese »etlichen Gefahren« noch nie in meinem professionellen Leben gesehen. Warum nicht? Weil ich Regeln für ein Modul so notiere (Sass, indented syntax):
.modul
color: red
+screen-min-sm
color: blue
+screen-min-lg
color: green
Das ist die logische und intuitive Reihenfolge, die das Layout von klein nach groß schrittweise aufbaut – und gleichzeitig die, die bei stacked MQs nötig ist. Warum sollte ich auch eine andere Reihenfolge notieren? In welchem Fall muss ich erst Regeln für größere Viewports notieren? Ich kenne keinen.
Selbst wenn ich stacked MQs verwenden würde, würde ich die Reihenfolge doch nicht umdrehen! Das wäre völlig verwirrend. Ich würde genauso schreiben:
.modul
+screen-xs
color: red
+screen-sm
color: blue
+screen-lg
color: green
Aber lassen wir das einfach mal dahingestellt sein, denn es geht ja eigentlich nur darum, dass wie oben erwähnt, man von Fall zu Fall (Einzelfallentscheidung) entscheiden sollte, und nicht "blind" einfach irgendeinem "Slogan" folgt.
Diesen Slogan gibt es nicht und niemand behauptet, man solle ihm »blind« folgen. Mir scheint, du konstruierst hier einen Strohmann und kämpfst gegen Windmühlen.
Was man vielleicht auch nicht vergessen sollte ist, dass es ja nicht nur "Professionals" gibt. Und ich behaupte einfach mal, dass 'overlapping MQs' für "Laien" wesentlich "unübersichtlicher" und somit nachteiliger sind!
Wir haben doch gerade festgestellt, dass keine der Techniken per se übersichtlicheren Code produziert, sondern es ganz darauf ankommt, ob Code zwischen den Viewport-Klassen wiederverwendet werden kann oder nicht.
Mathias
Hallo,
Anstatt zu propagieren, dass man pauschal immer den "Mobile first" Ansatz mit seinen overlapping MQs (min-width) verwendet, …
Himmel, wer tut das denn bitte?! Niemand!
Auf die Gefahr hin, mich zu wiederholen: »Mobile First« hat mit konkreten CSS-Techniken wenig zu tun. Wenn du mir auch nur eine einflussreiche Quelle nennst, die Mobile First *notwendig* mit overlapping MQs zusammenbringt und stacked *kategorisch ausschließt*, würde ich vielleicht verstehen, warum du hier so gegen Mobile First und overlapping MQs wetterst. Ich denke nicht, dass du eine finden wirst, sondern dass ein Missverständnis deinerseits vorliegt.
Das ist jetzt nicht dein Ernst Mathias ...!?
Prominentestes Beispiel: http://css-tricks.com/logic-in-media-queries/
Und unter den ersten 50 Google Suchtreffern zu "mobile first media queries" finden sich dutzende weitere Beispiele, genauso wie in Foren und Stackoverflow!
Es mag ja sein, dass dein Verständnis von "Mobile first" ein besseres/ differenzierteres/ genaueres ist. Mein Eindruck ist aber, dass du da zu der Minderheit gehörst.
Und ja, mag sein, dass bei mir da ein "Missverständnis" vorliegt. Dann aber bei tausenden anderen Usern auch ...!
Gruß Gunther
Hallo,
Prominentestes Beispiel: http://css-tricks.com/logic-in-media-queries/
Das bezieht sich auf die konkrete Anwendung von Media Queries. Es beschreibt, in welcher Reihenfolge und mit welcher Logik sich MQs notieren lassen. Deshalb gibt es dort auch »mobile first« *und* »desktop first«. Das bezieht sich lediglich auf die Reihenfolge, wie Styles überschrieben werden. Man hätte es genauso »small overrides wide« oder »wide overrides small« nennen können.
Das sind basale MQ-Techniken, mehr nicht. CSS Tricks ist kein Magazin, in dem Konzept- und Designentscheidungen diskutiert werden. Wenn ich von »Mobile First« spreche, meine ich das Produkt- und Designkonzept von Luke Wroblewski. Natürlich ist das mit obigen MQs verwandt, aus den genannten Gründen. Sie gehen oftmals miteinander Hand in Hand gehen, sind aber nicht identisch.
Mathias
Hallo!
Prominentestes Beispiel: http://css-tricks.com/logic-in-media-queries/
Das bezieht sich auf die konkrete Anwendung von Media Queries. Es beschreibt, in welcher Reihenfolge und mit welcher Logik sich MQs notieren lassen. Deshalb gibt es dort auch »mobile first« *und* »desktop first«. Das bezieht sich lediglich auf die Reihenfolge, wie Styles überschrieben werden. Man hätte es genauso »small overrides wide« oder »wide overrides small« nennen können.
Nein, es impliziert, dass man unter "Mobile first" die Verwendung von 'overlapping min-width MQs' versteht.
Was ja auch viele User tun ...!
Das sind basale MQ-Techniken, mehr nicht. CSS Tricks ist kein Magazin, in dem Konzept- und Designentscheidungen diskutiert werden.
Es hat aber nicht nur bei Google einen ziemlich "hohen Stellenwert".
Wenn ich von »Mobile First« spreche, meine ich das Produkt- und Designkonzept von Luke Wroblewski.
Sorry, aber ich habe das Buch immer noch nicht ...! Insofern weiß ich jetzt immer noch nicht mehr ...!
Also muss, um Missverständnisse zu vermeiden, jeder dazuschreiben, was er jetzt genau unter "Mobile first" versteht ...?
Und ehrlich gesagt halte ich es auch für etwas "realitätsfremd" bestreiten zu wollen, dass der Begriff "Mobile first" sehr häufig als Synonym für genau diese MQ-Technik verwendet wird.
Bezeichnenderweise gibt es auch weder in der Englischen, noch in der Deutschen Wikipedia einen Artikel "Mobile first". Vielmehr taucht es lediglich in der Englischen Ausgabe unter "Responsive Web Design" auf.
Natürlich ist das mit obigen MQs verwandt, aus den genannten Gründen. Sie gehen oftmals miteinander Hand in Hand gehen, sind aber nicht identisch.
Was grenzt denn dann bitte "Mobile first" von "RWD" ab, bzw. was sind die Unterschiede?
Nur dass ich bei der Layout- und Inhaltsplanung vom KAV ausgehe?
Gruß Gunther
Hallo,
Was grenzt denn dann bitte "Mobile first" von "RWD" ab, bzw. was sind die Unterschiede?
Nur dass ich bei der Layout- und Inhaltsplanung vom KAV ausgehe?
Responsive Design heißt erst einmal, dass ich unterschiedlichen Geräten angepasste Layouts gebe. Mobile First umschließt das, aber noch mehr:
http://www.lukew.com/ff/entry.asp?933
http://bradfrostweb.com/blog/mobile/the-many-faces-of-mobile-first/
Ja, bei der Inhaltsplanung wird von Mobilgeräten ausgegangen – nicht notwendig vom kleinstmöglichen Viewport. Viewports auf Mobilgeräten sind nicht mehr so klein. Selbst die üblichen 320px Breite sind bei einer Device-Pixel-Ratio von 2 oder 3 und entsprechenden Displaygrößen ziemlich viel.
Mathias
Hallo,
Was grenzt denn dann bitte "Mobile first" von "RWD" ab, bzw. was sind die Unterschiede?
Nur dass ich bei der Layout- und Inhaltsplanung vom KAV ausgehe?Responsive Design heißt erst einmal, dass ich unterschiedlichen Geräten angepasste Layouts gebe. Mobile First umschließt das, aber noch mehr:
http://www.lukew.com/ff/entry.asp?933
http://bradfrostweb.com/blog/mobile/the-many-faces-of-mobile-first/
Danke, das sorgt doch für etwas mehr Klarheit, was du meinst.
Und da sind wir aber auch schon gleich beim nächsten "Problem" von "Mobile first" ...!
Denn ich glaube, dass Luke seinerzeit unter dem Begriff "Mobile" im Wesentlichen nur Geräte mit kleinem Viewport, Touchscreen und "langsamer" GPRS Verbindung im Sinn hatte.
Wie definierst du denn heutzutage "Mobile"?
Ja, bei der Inhaltsplanung wird von Mobilgeräten ausgegangen – nicht notwendig vom kleinstmöglichen Viewport.
Sorry, aber das liest sich für mich bspw. in dem Artikel von Brad Frost ganz anders ...!
Viewports auf Mobilgeräten sind nicht mehr so klein. Selbst die üblichen 320px Breite sind bei einer Device-Pixel-Ratio von 2 oder 3 und entsprechenden Displaygrößen ziemlich viel.
Siehst du! Du schreibst ja schon selber:"Viewports auf Mobilgeräten sind nicht mehr so klein.".
Zusätzlich sei nochmal auf meine obige Frage verwiesen.
Und dann frage ich mich, wie viel ist dann noch von "Mobile first" übrig, bzw. welchen Sinn macht es (noch)?
Hinzukommt, dass zu der Zeit, wo Luke den Begriff samt zugehörigen Konzept "erfunden" hat, es noch (Desktop) Browser gab, die man durchaus seinerzeit noch unterstützen sollte, die von Hause aus keine MQs verstanden haben (IE 8).
Aber auch dieser Punkt ist heutzutage nicht mehr relevant, da man bei der Unterstützung des IE 8 und der Verwendung von HTML5 sowieso auf Javascript angewiesen ist, und somit auch auf entsprechende Polyfills für MQs zurückgreifen kann.
Gruß Gunther
Hallo,
Wenn ich von »Mobile First« spreche, meine ich das Produkt- und Designkonzept von Luke Wroblewski. Natürlich ist das mit obigen MQs verwandt, aus den genannten Gründen. Sie gehen oftmals miteinander Hand in Hand gehen, sind aber nicht identisch.
Falls es jemand interessiert, ich habe mir einmal das Buch gekauft und hineingeschaut.
Es geht darin um einen »business case for mobile first«. »You won’t find any code in this book; there are many programmers out there who can provide better advice on mobile development than I can.«
Zusammenfassung es Inhalts:
Kurz gesagt: Es geht hier nicht um konkrete CSS-Techniken, sondern um Grundwissen, dass Mobilgeräte sich verbreiten, wie sie bedient werden, wie man Websites für Mobilgeräte aufbaut, dass man flexible Websites bauen sollte. Es geht darum, den Fokus bei der Entwicklung von neuen Sites auf Mobilgeräte zu setzen, ohne andere Zugangs- und Nutzungsarten aus den Augen zu verlieren. Hinsichtlich der technischen Umsetzung wird auf das Buch von Ethan Marcotte, dem Namensgeber von RWD, verwiesen.
Mathias
@@Gunnar Bittersmann:
nuqneH
Wobei ich’s eigentlich sauberer finde, die Einheit dppx mit ins Argument zu nehmen:
@mixin resmq($res)
{
@media
(-webkit-min-device-pixel-ratio: $res/1dppx),
(min-resolution: $res * 96dpi/1dppx),
(min-resolution: $res)
{
@content;
}
}
Aufruf: @include resmq(2dppx);
Qapla'
@@Gunnar Bittersmann:
nuqneH
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?
Mein geschätzter Kollege hat mir grad ins Ohr geflüstert, beim UC-Browser sind es 19px.
Qapla'
@@Gunnar:
nuqneH
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?
Mein geschätzter Kollege hat mir grad ins Ohr geflüstert, beim UC-Browser sind es 19px.
Das ist dann ja noch im "Toleranzbereich" ...! ;-)
War ja klar, dass sich die Chinesen nicht danach richten, was der Rest der Welt macht.
Und solange deine potentielle Zielgruppe nicht hauptsächlich in China und Indien angesiedelt ist ... .
Da der Browser über seine eigene Engine /U3) verfügt, hat den hier eh noch keiner "auf dem Schirm".
Im Zweifelsfall muss dann halt entsprechende "Anpassungen/ Korrekturen" vornehmen.
Für die MQs dürfte es ja keinen Unterschied machen, solange der UC genau wie alle anderen Browser die (vom Benutzer) festgelegte Basis-Schriftgröße verwendet.
Gruß Gunther
@@Gunther:
nuqneH
War ja klar, dass sich die Chinesen nicht danach richten, was der Rest der Welt macht.
Da kann man ihnen auch keinen Vorwurf machen. Diejenigen, die nichtlateinische Zeichen oder lateinische Zeichen außerhalb von Latin-1 oder gar Nicht-ASCII-Zeichen (wie deutsche Umlaute) als „Sonderzeichen“ ansehen, richten sich auch nicht danach, wie der Rest der Welt schreibt.
CJK-Zeichen müssen etwas größer als lateinische (und verwandte griechische und kyrillische) Zeichen dargestellt werden, um lesbar zu sein. Für Devanagari u.a. indische Schriften mag das auch gelten.
Qapla'
Hallo,
Mein geschätzter Kollege hat mir grad ins Ohr geflüstert, beim UC-Browser sind es 19px.
Ich bin nicht gut in Mathe, aber: Solange es nicht signifikant weniger oder mehr ist, als ich annehme, greifen die stacked MQs korrekt.
Prämisse: Browser runden em-Werte in MQs kaufmännisch auf volle px, bevor sie angewendet werden.
Angenommen ich lasse die MQ bei x + 1/16em anfangen:
@media screen and … and (max-width: 50em)
@media screen and (min-width: 50.0625em) and …
Bei den genannten 19px wären 1/16em berechnete 1.1875px. Abgerundet 1px. Also würden die MQs funktionieren, es gäbe keinen »Zwischenraum«, in dem keine der beiden MQs greift.
Wenn ich hingegen eine Basis-Schriftgröße von 8px annehme:
1/16em * 8px = 0.5px
Wird aufgerundet auf 1px. *Darunter* (7px) würde es kritisch werden, dann würde abgerundet.
Anders herum: Wenn ich hingegen eine Basis-Schriftgröße von 24px hätte:
1/16em * 24px = 1.5px
Wird aufgerundet auf 2px. Damit gäbe es eine Viewport-Breite, in dem keine der beiden MQs greift.
Sprich, wenn ich von 16px ausgehe, habe ich eine Toleranz von 8px - 23px. (Man korrigiere mich.)
Das ist, behaupte ich einmal, in der Praxis genug, um Fehler zu vermeiden. Es kommt noch hinzu, dass der Viewport genau diese Pixelbreite haben muss, um den Fehler auszulösen. Das ist alles möglich, aber äußerst unwahrscheinlich. Die Wahrscheinlichkeit, dass ich nach dem Schreiben dieses Postings aus heiterem Himmel tot umfalle, ist vermutlich höher. ;)
Disclaimer:
Die Prämisse kann natürlich falsch sein, z.B. falls Sub-Pixel-Rendering angewandt wird, dann sind alle Schlüsse hinfällig.
Ich habe es nicht in Browsern getestet, das ist alles bloß theoretisch.
Mathias
Hallo Mathias!
Sorry, den Post habe ich eben gar nicht gesehen (der Thread wird langsam unübersichtlich). ;-)
Prämisse: Browser runden em-Werte in MQs kaufmännisch auf volle px, bevor sie angewendet werden.
So meine Erfahrungen (bisher) ...!
Angenommen ich lasse die MQ bei x + 1/16em anfangen:
@media screen and … and (max-width: 50em)
@media screen and (min-width: 50.0625em) and …Bei den genannten 19px wären 1/16em berechnete 1.1875px. Abgerundet 1px. Also würden die MQs funktionieren, es gäbe keinen »Zwischenraum«, in dem keine der beiden MQs greift.
Wenn ich hingegen eine Basis-Schriftgröße von 8px annehme:
1/16em * 8px = 0.5px
Wird aufgerundet auf 1px. *Darunter* (7px) würde es kritisch werden, dann würde abgerundet.
Anders herum: Wenn ich hingegen eine Basis-Schriftgröße von 24px hätte:
1/16em * 24px = 1.5px
Wird aufgerundet auf 2px. Damit gäbe es eine Viewport-Breite, in dem keine der beiden MQs greift.
Sprich, wenn ich von 16px ausgehe, habe ich eine Toleranz von 8px - 23px. (Man korrigiere mich.)
Sehe ich genauso!
Und wenn wir mal davon ausgehen, dass wenn überhaupt ein User die Schriftgröße ändert, er das tut, um alles "besser erkennen" zu können, sprich er eine größere Schriftgröße als die 16px einstellt, dann könnte man statt 1/16 auch ein 1/20 (0.05em) nehmen.
Dadurch verkleinert man zwar den Spielraum nach unten (auf >= 11px), gewinnt aber nach oben hin etwas dazu (auf <= 29px).
Das ist, behaupte ich einmal, in der Praxis genug, um Fehler zu vermeiden. Es kommt noch hinzu, dass der Viewport genau diese Pixelbreite haben muss, um den Fehler auszulösen. Das ist alles möglich, aber äußerst unwahrscheinlich. Die Wahrscheinlichkeit, dass ich nach dem Schreiben dieses Postings aus heiterem Himmel tot umfalle, ist vermutlich höher. ;)
Das wollen wir aber nicht hoffen, auch wenn du vermutlich Recht haben dürftest ...! ;-)
BTW: Ich empfehle jedem mal testweise seine Basis-Schriftgröße auf 28px einzustellen und dann durchs Web zu surfen ...!
Da sieht man dann u.a. mal, wie viele Sites einem die Schriftgröße "vorschreiben".
Gruß Gunther
@@Gunther:
nuqneH
BTW: Ich empfehle jedem mal testweise seine Basis-Schriftgröße auf 28px einzustellen und dann durchs Web zu surfen ...!
In seinem Browser pink als Hintergrundfarbe einzustellen dürfte auch spaßig sein.
Qapla'
@@Gunther:
nuqneH
Sorry, den Post habe ich eben gar nicht gesehen (der Thread wird langsam unübersichtlich). ;-)
Hast du dieses Posting denn gesehen?
Qapla'
@@Gunther:
nuqneH
(der Thread wird langsam unübersichtlich). ;-)
Protip: Nutzereinstellungen > Threads und Postings > Postings als gelesen markieren
Anhaken:
[X] Bereits besuchte Postings serverseitig als gelesen markieren
[X] Eigene Postings auch als gelesen markieren
[ ] Schriftfarbe
und/oder
[ ] Hintergrundfarbe
auf einen Wert setzen, der sich deutlich von ungelesenen Postings abhebt.
Qapla'
@@Gunnar:
nuqneH
(der Thread wird langsam unübersichtlich). ;-)
Protip: Nutzereinstellungen > Threads und Postings > Postings als gelesen markieren
Anhaken:
[X] Bereits besuchte Postings serverseitig als gelesen markieren
[X] Eigene Postings auch als gelesen markieren
Das habe ich bereits so eingestellt, und zusätzlich auch Mathias Skript im Einsatz, welches einem u.a. auch neue Antworten anzeigt. ;-)
[ ] Schriftfarbe
und/oder
[ ] Hintergrundfarbe
auf einen Wert setzen, der sich deutlich von ungelesenen Postings abhebt.
Ja, das sollte ich wohl zusätzlich auch noch machen ..., vielleicht hilft's! :-)
Gruß Gunther
Hallo Mathias!
Wird aufgerundet auf 2px. Damit gäbe es eine Viewport-Breite, in dem keine der beiden MQs greift.
Es kommt noch hinzu, dass der Viewport genau diese Pixelbreite haben muss, um den Fehler auszulösen.
Nur so ein Gedanke ..., aber könnte man mit Hilfe von Javascript nicht ggf. "feststellen", ob der Viewport genau diese Breite hat, die in die "MQ-Lücke" fällt?
Dann könnte man dem User zumindest einen Hinweis anzeigen lassen ... .
Ich wüsste nur grad nicht, wie man die eingestellte Basis-Schriftgröße kommen könnte (wenn überhaupt)!?
Gruß Gunther
@@Gunther:
nuqneH
Dann könnte man dem User zumindest einen Hinweis anzeigen lassen ... .
à la „Du hast etwas falsch gemacht (und nicht etwa wir)“?
Und was soll das bringen? Wissen denn wirklich viele Nutzer, dass man die Fenstergröße ändern kann (so man das auf $Gerät tatsächlich kann) oder betreiben viele ihren Browser u.a. Anwendungen ausschließlich im Vollbildmodus?
Qapla'
@@Gunnar:
nuqneH
Dann könnte man dem User zumindest einen Hinweis anzeigen lassen ... .
à la „Du hast etwas falsch gemacht (und nicht etwa wir)“?
Nein, natürlich nicht!
Wie kommst du bloß wieder auf solche Ideen ...!? :-P
Und was soll das bringen?
Dann kann man für den User ja ein "alternatives Stylesheet" (mit einem anderen Faktor) verwenden (sofern er Cookies akzeptiert).
Wissen denn wirklich viele Nutzer, dass man die Fenstergröße ändern kann (so man das auf $Gerät tatsächlich kann) oder betreiben viele ihren Browser u.a. Anwendungen ausschließlich im Vollbildmodus?
Keine Ahnung.
Deshalb würde ich so einen Ansatz aber auch erst gar nicht ernsthaft in Erwägung ziehen.
Gruß Gunther
Hallo,
Ich wüsste nur grad nicht, wie man die eingestellte Basis-Schriftgröße kommen könnte (wenn überhaupt)!?
<div id="tester" style="width: 1em"></div>
alert( document.getElementById('tester').offsetWidth )
Mathias
@@Gunnar:
nuqneH
Das "funktioniert" halt nur so lange zuverlässig, wie die Annahme "Basis-Schriftgröße = 16px" zutrifft.
Eben.
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).
Und was mit der Typografie!?
Stichwort "Golden Ratio" (font-size, line-height, line width) ...!
Das größte Problem ist doch, dass man per CSS keinerlei Möglichkeit hat, die im Browser eingestellte Basis-Schriftgröße zu berücksichtigen.
Da man aber für gewisse Dinge (s.o.) einen "bestimmten" (absoluten) Wert braucht, muss man deshalb von irgendeinem ausgehen!
Und da nehme ich dann halt '16'. :-P
Per JS kann man das natürlich (nachträglich) entsprechend "korrigieren".
Ich finde es auch äußerst "gelungen", dass man per CSS nicht auf eine solch eklatant wichtige Größe zurückgreifen kann.
Insbesondere da man sie auch durch nichts "überschreiben" kann, denn für die Auswertung von MQs wird in allen mir bekannten Browsern die dort eingestellte Basis-Schriftgröße verwendet. Da kann man in sein Stylesheet schreiben was man will ...! Das bringt dann höchstens alle anderen "Kalkulationen" durcheinander ...!
Na ja, vielleicht in CSS5, aber ob ich das noch erleben werde ...! ;-)
Gruß Gunther
@@Gunther:
nuqneH
Und was mit der Typografie!?
Stichwort "Golden Ratio" (font-size,
Was soll damit sein?
line-height
Wird ohne einheit oder in % relativ zur Schriftgröße angegeben.
line width) ...!
Ja, für Breiten von Boxen ist manchmal %, nicht em/rem angebracht. Letzteres eher für Minimal-/Maximalbreiten.
Das größte Problem ist doch, dass man per CSS keinerlei Möglichkeit hat, die im Browser eingestellte Basis-Schriftgröße zu berücksichtigen.
Da man aber für gewisse Dinge (s.o.) einen "bestimmten" (absoluten) Wert braucht, muss man deshalb von irgendeinem ausgehen!
Ich kann dir nicht ganz folgen.
Na ja, vielleicht in CSS5, aber ob ich das noch erleben werde ...! ;-)
Vermutlich nicht. Du wirst nicht einmal CSS4 erleben.
In dem Zusammenhang: Der Nachfolger von Media Queries sollte eigentlich nicht Media Queries Level 4 heißen, sondern Level 2.
Qapla'
@@Gunnar:
nuqneH
Und was mit der Typografie!?
Stichwort "Golden Ratio" (font-size,Was soll damit sein?
Siehe: http://www.pearsonified.com/2011/12/golden-ratio-typography.php
line-height
Wird ohne einheit oder in % relativ zur Schriftgröße angegeben.
line width) ...!
Ja, für Breiten von Boxen ist manchmal %, nicht em/rem angebracht. Letzteres eher für Minimal-/Maximalbreiten.
Das größte Problem ist doch, dass man per CSS keinerlei Möglichkeit hat, die im Browser eingestellte Basis-Schriftgröße zu berücksichtigen.
Da man aber für gewisse Dinge (s.o.) einen "bestimmten" (absoluten) Wert braucht, muss man deshalb von irgendeinem ausgehen!
Ich kann dir nicht ganz folgen.
Wie machst du das denn bezüglich der Typografie in 'em'!?
Um bspw. die "Golden Ratio" Proportionen zu berechnen, braucht es doch Pixelwerte, bzw. deren entsprechendes Äquivalent aus den EM-Werten. Und bei jeder "Umrechnung" von relativen in absolute Einheiten, brauchst du doch eine "Basisgröße", oder hab' ich was verpasst?
Rein in den relativen EInheiten würde das nur funktionieren, wenn man eben auf die eingestellte Basis-Schriftgröße zugreifen könnte - kann man aber nicht.
Na ja, vielleicht in CSS5, aber ob ich das noch erleben werde ...! ;-)
Vermutlich nicht. Du wirst nicht einmal CSS4 erleben.
Stimmt - habe ich nicht dran gedacht.
Gruß Gunther
@@Gunther:
nuqneH
Siehe: http://www.pearsonified.com/2011/12/golden-ratio-typography.php
[X] Du hast nicht erkannt, dass der Artikel ein Aprilscherz ist.
[X] Du hat die Mathematik nicht durchschaut.
[X] Du hast die Kommentare nicht gelesen.
Qapla'
@@Gunnar:
nuqneH
Siehe: http://www.pearsonified.com/2011/12/golden-ratio-typography.php
[X] Du hast nicht erkannt, dass der Artikel ein Aprilscherz ist.
[X] Du hat die Mathematik nicht durchschaut.
[X] Du hast die Kommentare nicht gelesen.
OK, mal angenommen, deine Kreuzchen treffen alle zu, wie setzt du deine line-height?
Ich finde den Ansatz, die line-height (neben der font-size) auch von der line width abhängig zu machen, gar nicht so verkehrt.
Gruß Gunther
@@Gunther:
nuqneH
wie setzt du deine line-height?
calc(1.1em + 1vw) funktioniert in Chrome. Firefox wendet das bei margin, aber (noch?) nicht bei line-height an. Safari weder noch.
Ich finde den Ansatz, die line-height (neben der font-size) auch von der line width abhängig zu machen, gar nicht so verkehrt.
Natürlich nicht.
Qapla'
@@Gunnar:
nuqneH
wie setzt du deine line-height?
calc(1.1em + 1vw) funktioniert in Chrome. Firefox wendet das bei margin, aber (noch?) nicht bei line-height an. Safari weder noch.
Hmmm ..., mal ganz davon abgesehen, dass das aktuell nur im Chrome funktioniert, berücksichtigt das in keinster Weise die 'line width' (sondern nur die Viewportbreite).
Dann könnte man ja bspw. lieber gleich schreiben:
p {
margin: calc(1.1em + 1%) 0;
}
Auch das funktioniert nur im Chrome.
BTW: Ich hätte erwartet, dass für das HTML-Element gilt: 1% = 1vw
Das scheint aber offensichtlich nicht so zu sein ...!?
Ich finde den Ansatz, die line-height (neben der font-size) auch von der line width abhängig zu machen, gar nicht so verkehrt.
Natürlich nicht.
Schön wenn du das auch so siehst, nur berücksichtigen tust du es nicht ...!?
Und leider ist calc() hier auch keine "Hilfe", denn abgesehen davon, dass aktuell nur Chrome eine entsprechende Angabe für 'line-height' unterstützt, ist das, was wirklich hilfreich wäre, nämlich z.B.:
div {
max-width: calc(1em / 1rem * 40rem);
}
generell nicht möglich, da der Divisor immer eine <number> sein muss!
Und auch bei Multiplikationen muss mindestens eine <number> enthalten sein.
Als derzeitiges (Zwischen-)Fazit frage ich mich, was in der Praxis nun besser ist:
Dein Ansatz, oder die Berechnung, die auf der Annahme basiert, dass die Basis-Schriftgröße ~ 16 px entspricht (und selbst bei abweichender Schriftgröße immer noch "brauchbare" Ergebnisse liefert)?
Und sich per JS dann auch noch entsprechend korrigieren lässt ...!
Gruß Gunther
@@Gunnar:
nuqneH
Nachtrag 1:
wie setzt du deine line-height?
calc(1.1em + 1vw) funktioniert in Chrome. Firefox wendet das bei margin, aber (noch?) nicht bei line-height an. Safari weder noch.
Also "interessiert" dich die Accessibility (WCAG 2.0) nicht (wirklich ~ Level AAA)? :-P
Siehe: Visual Presentation
Gruß Gunther
@@Gunther:
nuqneH
Also "interessiert" dich die Accessibility (WCAG 2.0) nicht (wirklich ~ Level AAA)? :-P
Siehe: Visual Presentation
Steht da was davon, den Zeilenabstand an die Lautweite anzupassen?
Qapla'
@@Gunnar:
nuqneH
Also "interessiert" dich die Accessibility (WCAG 2.0) nicht (wirklich ~ Level AAA)? :-P
Siehe: Visual Presentation
Steht da was davon, den Zeilenabstand an die Lautweite anzupassen?
Meintest du Laufweite?
Falls nicht, verstehe ich grad nicht, was du meinst.
Andernfalls:
Nein, steht nichts davon.
Dort steht ja nur etwas zur Zeilenhöhe und dem Abstand zwischen Absätzen.
Ich mache es im Prinzip so:
Mir genügt das, jedenfalls solange, bis andere "Methoden" browserübergreifend verwendet werden können.
Gruß Gunther
@@Gunther:
nuqneH
Steht da was davon, den Zeilenabstand an die Lautweite anzupassen?
Meintest du Laufweite?
Nein. Falschen Begriff verwendet. Ich meinte Satzbreite.
- Zeilenhöhe: 1,5 fache Schriftgröße
Kann man so pauschal nicht sagen. Glyphen verschiedener Schriftarten gleicher Nominalgröße können unterschiedlich groß sein (x-Höhe). Für ein ähnliches Erscheinungsbild muss man die Zeilenhöhe der Schriftart anpassen.
Und bei geringer Satzbreite (jetzt aber!) kann die Zeilenhöhe durchaus geringer sein. Die WCAG sollte kein Dogma sein.
- Abstand Absätze: 2,25 (1,5 x 1,5) fache Schriftgröße
Das widerspricht der jahrhundertelangen Tradition im Buchdruck, wo es keine Abstände zwischen Absätzen gab.
Manche sind auch Verfechter von vertikalem Rhythmus. Dann sollte der Abstand zwischen Absätzen so groß sein, dass die Grundlinien von letzer/erster Zeile doppelten Abstand zueinander haben wie die Grundlinien innerhalb eines Absatzes. Das heißt, es sollte tatsächlich so aussehen wie eine „Leerzeile“.
Qapla'
@@Gunnar:
nuqneH
Steht da was davon, den Zeilenabstand an die Lautweite anzupassen?
Meintest du Laufweite?
Nein. Falschen Begriff verwendet. Ich meinte Satzbreite.
OK.
- Zeilenhöhe: 1,5 fache Schriftgröße
Kann man so pauschal nicht sagen. Glyphen verschiedener Schriftarten gleicher Nominalgröße können unterschiedlich groß sein (x-Höhe). Für ein ähnliches Erscheinungsbild muss man die Zeilenhöhe der Schriftart anpassen.
Ja, und wie?
Und bei geringer Satzbreite (jetzt aber!) kann die Zeilenhöhe durchaus geringer sein.
Um wie viel?
Die WCAG sollte kein Dogma sein.
Dogma hin oder her ..., aber an irgendetwas muss man sich ja zumindest orientieren!
- Abstand Absätze: 2,25 (1,5 x 1,5) fache Schriftgröße
Das widerspricht der jahrhundertelangen Tradition im Buchdruck, wo es keine Abstände zwischen Absätzen gab.
Ausgerechnet du stellst jetzt eine "Verbindung" zwischen Print Medien und dem Web her ...!? :-P
Und wenn es da keine Abstände gab, wodurch war denn dann ein Absatz gekennzeichnet?
Manche sind auch Verfechter von vertikalem Rhythmus. Dann sollte der Abstand zwischen Absätzen so groß sein, dass die Grundlinien von letzer/erster Zeile doppelten Abstand zueinander haben wie die Grundlinien innerhalb eines Absatzes. Das heißt, es sollte tatsächlich so aussehen wie eine „Leerzeile“.
Die Default Einstellung in vielen Browser Stylesheets sieht hingegen so aus:
p {
margin: 1em 0;
}
Und wenn ich dich richtig verstanden habe, dann meinst du (bei einer angenommenen line-height von 1.5):
p {
margin: 1.5em 0;
}
Also 'font-size * line-height' ~ 'line-height * 1em'
Es bleibt also dabei, dass alles auf die Frage hinausläuft:"Wie setze ich meine line-height?"
Gruß Gunther
@@Gunther:
nuqneH
Glyphen verschiedener Schriftarten gleicher Nominalgröße können unterschiedlich groß sein (x-Höhe). Für ein ähnliches Erscheinungsbild muss man die Zeilenhöhe der Schriftart anpassen.
Ja, und wie?
Nach Augenmaß.
Und bei geringer Satzbreite (jetzt aber!) kann die Zeilenhöhe durchaus geringer sein.
Um wie viel?
Nach Augenmaß.
Das widerspricht der jahrhundertelangen Tradition im Buchdruck, wo es keine Abstände zwischen Absätzen gab.
Ausgerechnet du stellst jetzt eine "Verbindung" zwischen Print Medien und dem Web her ...!? :-P
Naja, wenn’s ums Textblöcke geht, sollte das erlaubt sein.
Übrigens ist das Setzen von Abständen zwischen Absätzen längst aus dem Web auf Prinfmedien übergeschwappt. Ich sag das nur feststellend, nicht wertend.
Und wenn es da keine Abstände gab, wodurch war denn dann ein Absatz gekennzeichnet?
Durch Einzug der ersten Zeile. Geht auch im Web:
p
{
margin: 0;
text-indent: 1em;
}
Manche sind auch Verfechter von vertikalem Rhythmus. […]
Und wenn ich dich richtig verstanden habe
Hast du.
Es bleibt also dabei, dass alles auf die Frage hinausläuft:"Wie setze ich meine line-height?"
Wie gezeigt? Fester Wert als Basis, Abhängigkeit von Satzbreite als progressive enhancement.
Qapla'
@@Gunnar:
nuqneH
Glyphen verschiedener Schriftarten gleicher Nominalgröße können unterschiedlich groß sein (x-Höhe). Für ein ähnliches Erscheinungsbild muss man die Zeilenhöhe der Schriftart anpassen.
Ja, und wie?
Nach Augenmaß.
Ich sehe, wir nähern uns an ...! ;-)
Wobei ich dann wiederum nicht unbedingt sehe, was dagegen sprechen sollte, sich unter diesen Umständen nicht an die Vorgabe der WCAG (>= 1.5) zu halten.
Denn lieber eine größere Zeilenhöhe, als eine zu geringe.
Und bei geringer Satzbreite (jetzt aber!) kann die Zeilenhöhe durchaus geringer sein.
Um wie viel?
Nach Augenmaß.
Manche sind auch Verfechter von vertikalem Rhythmus. […]
Und wenn ich dich richtig verstanden habeHast du.
Beruhigend! ;-)
Es bleibt also dabei, dass alles auf die Frage hinausläuft:"Wie setze ich meine line-height?"
Wie gezeigt? Fester Wert als Basis,
Soweit so gut ...
Abhängigkeit von Satzbreite als progressive enhancement.
... und das dann aktuell per JS (da mit CSS nicht möglich!).
Mit "nicht möglich" meine ich, dass calc() für line-height aktuell nur von Chrome unterstützt wird, und dass man dafür die Breite des Elements kennen muss, auf die man auch per calc() nicht zugreifen kann, da sich ja bspw. Prozentwerte auf die Schriftgröße, und nicht auf die Dimensionen des Elements beziehen.
Gruß Gunther
@@Gunther:
nuqneH
Glyphen verschiedener Schriftarten gleicher Nominalgröße können unterschiedlich groß sein (x-Höhe). Für ein ähnliches Erscheinungsbild muss man die Zeilenhöhe der Schriftart anpassen.
Ja, und wie?
Nach Augenmaß.
Ich sehe, wir nähern uns an ...! ;-)
Eine An*gleich*ung ist aber nicht möglich, da man nie weiß, welche Schriftart beim Nutzer verwendet wird. Auch kann das Verhältnis x-Höhe zu Schriftgröße für dieselbe Schrift auf verschiedenen Systemen unterschiedlich sein.
Wobei ich dann wiederum nicht unbedingt sehe, was dagegen sprechen sollte, sich unter diesen Umständen nicht an die Vorgabe der WCAG (>= 1.5) zu halten.
Denn lieber eine größere Zeilenhöhe, als eine zu geringe.
Durchaus möglich, dass die Kurve für Lesbarkeit in Abhängigkeit vom Zeilenabstand vom Optimum zu höheren Abständen flacher abfällt als zu geringeren.
Abhängigkeit von Satzbreite als progressive enhancement.
... und das dann aktuell per JS (da mit CSS nicht möglich!).
Mit "nicht möglich" meine ich, dass calc() für line-height aktuell nur von Chrome unterstützt wird,
Mit „progressive enhancement“ meine ich, dass nur in Browsern, die das mit CSS hinbekommen, enhancet wird. Gegenwärtig dann halt nur Chrome.
Dafür ein JavaScript zu schreiben, ist wohl eher graceful degradation.
Und bis man das fertig hat, ist vielleicht schon der nächste Firefox draußen, der das auch mit calc() kann.
und dass man dafür die Breite des Elements kennen muss,
Dass man die i.d.R. kennt, erwähnte ich schon.
auf die man auch per calc() nicht zugreifen kann, da sich ja bspw. Prozentwerte auf die Schriftgröße, und nicht auf die Dimensionen des Elements beziehen …
Deshalb ja vw, nicht %.
Qapla'
@@Gunnar:
nuqneH
Glyphen verschiedener Schriftarten gleicher Nominalgröße können unterschiedlich groß sein (x-Höhe). Für ein ähnliches Erscheinungsbild muss man die Zeilenhöhe der Schriftart anpassen.
Ja, und wie?
Nach Augenmaß.
Ich sehe, wir nähern uns an ...! ;-)
Eine An*gleich*ung ist aber nicht möglich, da man nie weiß, welche Schriftart beim Nutzer verwendet wird.
Da hast du Recht, insoweit der User bspw. eigene Schriftarten verwendet.
Ansonsten kann man dem nur versuchen entgegenwirken, indem man per '@font-face' eine entsprechende Schriftart einbindet.
Auch kann das Verhältnis x-Höhe zu Schriftgröße für dieselbe Schrift auf verschiedenen Systemen unterschiedlich sein.
Hier hilft dann nur UA-Sniffing ...
Wobei ich dann wiederum nicht unbedingt sehe, was dagegen sprechen sollte, sich unter diesen Umständen nicht an die Vorgabe der WCAG (>= 1.5) zu halten.
Denn lieber eine größere Zeilenhöhe, als eine zu geringe.
Durchaus möglich, dass die Kurve für Lesbarkeit in Abhängigkeit vom Zeilenabstand vom Optimum zu höheren Abständen flacher abfällt als zu geringeren.
Kann ja jeder halten, wie er meint ...!
Abhängigkeit von Satzbreite als progressive enhancement.
... und das dann aktuell per JS (da mit CSS nicht möglich!).
Mit "nicht möglich" meine ich, dass calc() für line-height aktuell nur von Chrome unterstützt wird,
Mit „progressive enhancement“ meine ich, dass nur in Browsern, die das mit CSS hinbekommen, enhancet wird. Gegenwärtig dann halt nur Chrome.
Dafür ein JavaScript zu schreiben, ist wohl eher graceful degradation.
Ob progressive enhancement oder graceful degradation ist wohl eine Frage des Ausgangspunkt.
Ich sehe es als eine Basis per CSS für alle Browser und dementsprechend enhanced per JS, bzw. wo möglich per CSS.
Als was man das dann bezeichnet, ist mir aber im Endeffekt auch "wurscht".
Und bis man das fertig hat, ist vielleicht schon der nächste Firefox draußen, der das auch mit calc() kann.
Den dann natürlich auch sofort jeder verwendet ...! :-P
Und von den 20 anderen Browsern "out in the wild" ganz zu schweigen.
Irgendwo haben die Möglichkeiten des Testens ja auch ihre Grenzen ...!
und dass man dafür die Breite des Elements kennen muss,
Dass man die i.d.R. kennt, erwähnte ich schon.
auf die man auch per calc() nicht zugreifen kann, da sich ja bspw. Prozentwerte auf die Schriftgröße, und nicht auf die Dimensionen des Elements beziehen …
Deshalb ja vw, nicht %.
Das nutzt dir rein gar nichts!
Es geht doch um die Zeilenhöhe in Abhängigkeit der Zeilenbreite. Und die Zeilenbreite kann ja völlig unabhängig von der Viewportbreite sein.
Du hattest vorgeschlagen:
html {
line-height: calc(1.1em + 1vw);
}
Wenn ich jetzt z.B. ein 3-Spalten Layout habe, wie in meinem vorigen Beispiel angeführt, und somit bspw. für die beiden äußeren Spalten eine Breitenangabe habe wie:
.col {
width: 30%;
max-width: 30rem;
}
dann sagt das immer noch nichts über die Schriftgröße, noch die Zeilenbreite, noch die tatsächliche prozentuale Breite dieser Spalte aus.
Ich verstehe ehrlich gesagt (noch) nicht, wie man das Problem mittels 'vw' lösen können soll!?
Gruß Gunther
@@Gunther:
nuqneH
Hier hilft dann nur UA-Sniffing ...
Den Würgreflex mal kurz unterdrückt – Kann man damit verschiedene Linux-Distributionen auseinanderhalten?
Mit „progressive enhancement“ meine ich, dass nur in Browsern, die das mit CSS hinbekommen, enhancet wird. Gegenwärtig dann halt nur Chrome.
Dafür ein JavaScript zu schreiben, ist wohl eher graceful degradation.
Ob progressive enhancement oder graceful degradation ist wohl eine Frage des Ausgangspunkt.
Ich sehe es als eine Basis per CSS für alle Browser und dementsprechend enhanced per JS, bzw. wo möglich per CSS.
Andere Gedankenwelt. Du: Features für alte Browser auch zu implementieren. Progressive enhancement: fähige Clients bekommen besseres Feature, unfähige das Basisfeature.
Deshalb ja vw, nicht %.
Das nutzt dir rein gar nichts!
Es geht doch um die Zeilenhöhe in Abhängigkeit der Zeilenbreite. Und die Zeilenbreite kann ja völlig unabhängig von der Viewportbreite sein.
Ist sie bei fluid grids aber nicht. Wenn ein Element mit 38.2% Breite in einem Container mit 61.8% der Viewportbreite steckt, dann ist das eben 23.6vw breit (bei null margin/padding von html/body).
Wegen DRY wird man die Breiten(verhältnisse) in Sass in Variablen packen:
$container-width: 61.8%;
$element-width: 38.2%;
#container { width: $container-width; }
#element
{
width: $element-width;
line-height: 1.5;
line-height: calc(1.1em + #{$container-width * $container-width}vw);
}
Qapla'
@@Gunnar Bittersmann:
nuqneH
line-height: calc(1.1em + #{$container-width * $container-width}vw);
Bevor’s jemand merkt: calc(1.1em + #{$container-width / 1% * $element-width / 100%}vw);
Qapla'
@@Gunnar:
nuqneH
line-height: calc(1.1em + #{$container-width * $container-width}vw);
Bevor’s jemand merkt:
calc(1.1em + #{$container-width / 1% * $element-width / 100%}vw);
Die 23.6vw sind aber ein exorbitant großer Wert ...! :-P
Also eher so etwas wie:
calc(1.1em + #{$container-width / 1% * $element-width / 100% / 100}vw);
Aber die Viewport-Einheiten haben ein "generelles" Problem, wenn es um Schriftgröße, bzw. damit verbundene Größen wie line-height geht - sie skalieren beim Zoomen im Browser nicht!
Zusätzlich hast du ja selbst schon geschrieben, dass das im Prinzip nur bei fluiden Layouts funktioniert, wenn man zusätzlich noch die Elementbreite in Prozent kennt.
Das ist bspw. bei Verwendung von Flexbox aber nicht zwingend der Fall (ist ja gerade einer der Vorteile von Flexbox, diese nicht kennen zu müssen).
Also alles in allem erscheint mir das höchstens eine "Variante" für einen bestimmten Layout-Typ zu sein, die noch dazu aktuell nur sehr "eingeschränkt" anwendbar ist, aufgrund mangelnder Browserunterstützung.
Das grundlegende Problem ist aber, dass man in CSS bei der line-height keine Verbindung/ keinen Bezug zur Elementbreite herstellen kann.
Gruß Gunther
@@Gunther:
nuqneH
Hmmm ..., mal ganz davon abgesehen, dass das aktuell nur im Chrome funktioniert, berücksichtigt das in keinster Weise die 'line width' (sondern nur die Viewportbreite).
Die Breite der Box (in Prozent der Viewportbreite) hat man üblicherweise unter Kontrolle.
Dann könnte man ja bspw. lieber gleich schreiben:
p {
margin: calc(1.1em + 1%) 0;
}
Für margin ja; für line-height nicht, da würde sich % auf die Schriftgröße beziehen.
> Auch das funktioniert nur im Chrome.
Nö, im Firefox (31 auf MacOS) funktioniert das auch.
> BTW: Ich hätte erwartet, dass für das HTML-Element gilt: 1% = 1vw
> Das scheint aber offensichtlich nicht so zu sein ...!?
Nicht? Doch, dem ist so.
Wenn html/body margin/padding haben, macht bei untergeordneten Elementen % und vw natürlich einen Unterschied.
> > > Ich finde den Ansatz, die line-height (neben der font-size) auch von der line width abhängig zu machen, gar nicht so verkehrt.
> Schön wenn du das auch so siehst, nur berücksichtigen tust du es nicht ...!?
\*Ich\* schon. Firefox nicht. ;-)
> Und leider ist calc() hier auch keine "Hilfe", denn abgesehen davon, dass aktuell nur Chrome eine entsprechende Angabe für 'line-height' unterstützt, ist das, was wirklich hilfreich wäre, nämlich z.B.:
> ~~~css
div {
> max-width: calc(1em / 1rem * 40rem);
> }
>
generell nicht möglich,
Kann dir nicht folgen. Warum schreibst du nicht gleich 40em?
da der Divisor immer eine <number> sein muss!
Hach, wie wird man von Sass verwöhnt.
Qapla'
@@Gunnar:
nuqneH
Hmmm ..., mal ganz davon abgesehen, dass das aktuell nur im Chrome funktioniert, berücksichtigt das in keinster Weise die 'line width' (sondern nur die Viewportbreite).
Die Breite der Box (in Prozent der Viewportbreite) hat man üblicherweise unter Kontrolle.
Hier trifft man aber auch gleich auf eines der aktuellen Probleme bei der Layoutgestaltung und der Verwendung von 'em' basierten Media Queries.
Jeder der aktuell relevanten Browser verwendet zur Berechnung die im Browser eingestellte Basis-Schriftgröße.
Angenommen ich habe jetzt folgende MQ:
@media screen and (min-width: 100em) {...}
Wenn ich jetzt bspw. ein 3-spaltiges Layout erreichen möchte mit den Breiten
30em | 40em | 30em
dann könnte man sehr schnell eine Überraschung erleben (gilt nur für Browser mit "permanenter" Scrollbar) ...!
Denn mittlerweile machen es alle Browser (auch Webkit) gemäß der Spec und berücksichtigen bei der MQ keine Scrollbars!
Das bedeutet, dass wenn der Viewport (ohne Scrollbar) exakt den 100em Breite entspricht, man trotzdem nicht davon ausgehen kann, dass auch tatsächlich für die Elemente 100em Breite zur Verfügung stehen.
Ich brauche wohl nicht zu erwähnen, dass man per CSS nicht auf eine eventuelle Scrollbar-Breite zugreifen kann.
Und ferner ist die Scrollbar-Breite "variabel" ..., auch wenn sie auf vielen Systemen und deren Browsern 17px (wie passend, wo die Basis-Schriftgröße meist 16px entspricht) beträgt.
Um also vor "Überraschungen" sicher zu sein, müsste man Prozentwerte verwenden, denn 100% entsprechen der Viewportbreite_ohne_Scrollbar - also in diesem Beispiel:
30% | 40% | 30%
Das führt aber zu einem ungleich anderen Ergebnis!
Denn während die Verwendung von 'em' zu festen Breiten führt, sind die Spaltenbreiten mit '%' variabel.
Um das zu verhindern (bspw. weil man eine max. Zeilenlänge erreichen möchte), muss man also jeder Spalte zusätzlich noch eine 'max-width' Angabe hinzufügen.
Dann könnte man ja bspw. lieber gleich schreiben:
p {
margin: calc(1.1em + 1%) 0;
}
>
> Für margin ja; für line-height nicht, da würde sich % auf die Schriftgröße beziehen.
Autsch! Ja, da war mein "Denkfehler" ...!
> > Auch das funktioniert nur im Chrome.
>
> Nö, im Firefox (31 auf MacOS) funktioniert das auch.
Neein ..., immer nur für 'margin'.
Es ging und geht aber um die 'line-height'!
Du hast 'margin' doch nur ins Spiel gebracht, weil das außer in Chrome auch noch im Firefox funktioniert. Das ist aber in diesem Zusammenhang völlig irrelevant! :-P
> > > > Ich finde den Ansatz, die line-height (neben der font-size) auch von der line width abhängig zu machen, gar nicht so verkehrt.
> > Schön wenn du das auch so siehst, nur berücksichtigen tust du es nicht ...!?
>
> \*Ich\* schon. Firefox nicht. ;-)
Wie war das noch gleich?
[Zitat]Frickler können mit Unzulänglichkeiten leben, Entwickler nicht.[/Zitat]
> > Und leider ist calc() hier auch keine "Hilfe", denn abgesehen davon, dass aktuell nur Chrome eine entsprechende Angabe für 'line-height' unterstützt, ist das, was wirklich hilfreich wäre, nämlich z.B.:
> > ~~~css
div {
> > max-width: calc(1em / 1rem * 40rem);
> > }
> >
generell nicht möglich,
Kann dir nicht folgen. Warum schreibst du nicht gleich 40em?
Das war ja auch nur als Beispiel dafür gedacht, um zu demonstrieren, dass man per calc() keine Berechnungen basierend auf der vom User eingestellten Basis-Schriftgröße durchführen kann.
Dass es hier eine ganz einfache Alternative gibt, ist eine Unzulänglichkeit des Beispiels ...!
da der Divisor immer eine <number> sein muss!
Hach, wie wird man von Sass verwöhnt.
Nö, daran ändert auch SASS nichts, da es als Preprocessor niemals irgendwelche tatsächlichen Werte des Browsers berücksichtigen kann.
Also bist du genauso auf die Verwendung von calc() angewiesen, wie ohne SASS - mit den dementsprechenden "Einschränkungen" von calc().
Gruß Gunther
@@Gunther:
nuqneH
Wenn ich jetzt bspw. ein 3-spaltiges Layout erreichen möchte mit den Breiten
30em | 40em | 30em
Möchte man das?
Eine der 3 Säulen von RWD sind fluid grids – Breitenangaben in %.
Nö, im Firefox (31 auf MacOS) funktioniert das auch.
Neein ..., immer nur für 'margin'.
„Das“ bezog sich hier nur auf margin.
*Ich* schon. Firefox nicht. ;-)
Wie war das noch gleich?
[Zitat]Frickler können mit Unzulänglichkeiten leben, Entwickler nicht.[/Zitat]
Stacked MQs mit calc () und em und px sind eine systematische Unzulänglichkeit.
Nichtunterstützung von Features ist eine gänzlichlich andersartige. Und eine temporäre.
Und überhaupt würde ich progressive enhancement nicht „Unzulänglichkeit“ nennen. Mit progressive enhancement können Entwickler leben. Sehr gut sogar.
Frickler vielleicht nicht.
Qapla'
@@Gunnar Bittersmann:
nuqneH
Firefox wendet das bei margin, aber (noch?) nicht bei line-height an.
Mir wurde gerade ins Ohr geflüstert, dass das entsprechende Ticket bald seinen 4. Geburtstag feiert.
Qapla'
@@Gunnar Bittersmann:
nuqneH
Ich finde den Ansatz, die line-height (neben der font-size) auch von der line width abhängig zu machen, gar nicht so verkehrt.
Natürlich nicht.
Mir kommen die Formeln aber etwas seltsam vor.
Qapla'
@@Gunnar Bittersmann:
nuqneH
Mir kommen die Formeln aber etwas seltsam vor.
Sehr seltsam sogar, siehe anderen Thread.
Qapla'
@@Gunnar Bittersmann:
nuqneH
Wie machst du das? Mit
not? Oder wie umgehst du diese Problematik?
Gerade mal nachgelesen: Mit not geht’s (noch) gar nicht. not ist ja nur für den gesamten Query erlaubt, nicht für einzelne Teile.
Das ändert sich erst in Level 4. In eins, zwei Jahren kann man dan auch stacked MQs mit em machen …
Qapla'
@@Gunnar:
nuqneH
Wie machst du das? Mit
not? Oder wie umgehst du diese Problematik?Gerade mal nachgelesen: Mit
notgeht’s (noch) gar nicht.notist ja nur für den gesamten Query erlaubt, nicht für einzelne Teile.Das ändert sich erst in Level 4. In eins, zwei Jahren kann man dan auch stacked MQs mit em machen …
Erzähl' nicht so einen Quatsch ...! :-P
Natürlich ist das aktuell noch eine "Unzulänglichkeit", aber wie wahrscheinlich ist es denn, dass diese tatsächlich zum Tragen kommt!?
Und selbst wenn ...!
Ich hatte ja schon mal gefragt, wer überhaupt und warum die Basis-Schriftgröße in seinem Browser verstellt, anstatt die Zoom Funktion zu nutzen!?
Es war schon immer so, und wird imho auch immer so bleiben, dass man Webseitenautor nicht alle Fehler & Unzulänglichkeiten seitens der Spezifikation, Browserhersteller und Anwender zu 100% ausschließen/ vermeiden/ umgehen kann (oder muss)!
Gruß Gunther
@@Gunther:
nuqneH
Natürlich ist das aktuell noch eine "Unzulänglichkeit", aber wie wahrscheinlich ist es denn, dass diese tatsächlich zum Tragen kommt!?
Frickler können mit Unzulänglichkeiten leben, Entwickler nicht.
Ich hatte ja schon mal gefragt, wer überhaupt und warum die Basis-Schriftgröße in seinem Browser verstellt, anstatt die Zoom Funktion zu nutzen!?
Wir hatten doch schon geklärt, dass von „verstellen“ keine Rede sein muss, weil sie gar nicht einheitlich auf 16px gestellt ist.
Qapla'
@@Gunnar:
nuqneH
Natürlich ist das aktuell noch eine "Unzulänglichkeit", aber wie wahrscheinlich ist es denn, dass diese tatsächlich zum Tragen kommt!?
Frickler können mit Unzulänglichkeiten leben, Entwickler nicht.
Das mag sein ...!
Dann müssen "Entwickler" eben so lange noch mit overlapping MQs (und ihren Nachteilen) leben, bis in ein, zwei Jährchen ..., vielleicht und überhaupt!
Ich hatte ja schon mal gefragt, wer überhaupt und warum die Basis-Schriftgröße in seinem Browser verstellt, anstatt die Zoom Funktion zu nutzen!?
Wir hatten doch schon geklärt, dass von „verstellen“ keine Rede sein muss, weil sie gar nicht einheitlich auf 16px gestellt ist.
Ja, du hast bis jetzt eine Ausnahme gefunden.
Die werte ich jetzt mal als die berühmte Ausnahme, die die Regel bestätigt.
Natürlich würde ich mir auch wünschen, dass diese Unzulänglichkeit schnellstmöglich beseitigt wird, aber das liegt ja nicht an mir.
Gruß Gunther
@@Gunther:
nuqneH
Wir hatten doch schon geklärt, dass von „verstellen“ keine Rede sein muss, weil sie gar nicht einheitlich auf 16px gestellt ist.
Ja, du hast bis jetzt eine Ausnahme gefunden.
Die werte ich jetzt mal als die berühmte Ausnahme, die die Regel bestätigt.
Ich zweifle, ob du den Sinn von em verstanden hast.
Wenn 1em === 16px gelten würde, könnte man das mit den verschiedenen Einheiten ja ganz sein lassen.
Qapla'
@@Gunnarr:
nuqneH
Wir hatten doch schon geklärt, dass von „verstellen“ keine Rede sein muss, weil sie gar nicht einheitlich auf 16px gestellt ist.
Ja, du hast bis jetzt eine Ausnahme gefunden.
Die werte ich jetzt mal als die berühmte Ausnahme, die die Regel bestätigt.Ich zweifle, ob du den Sinn von em verstanden hast.
Wenn 1em === 16px gelten würde, könnte man das mit den verschiedenen Einheiten ja ganz sein lassen.
Nein, du musst nicht "zweifeln" - das ist mir schon klar.
Es geht ja gerade darum, dass ein User seine Basis-Schriftgröße ändern kann/ können soll, ohne dass deshalb das Layout "kollabiert".
Nur solange es eben keine andere Möglichkeit gibt, muss man ja irgendetwas als "Referenzfaktor" annehmen, um per 'em' möglichst auf 1px zu kommen.
Dabei fällt mir gerade so ein, dass man natürlich auch 1/20 (0,05em) nehmen könnte.
Das "passt" für die häufigste Variante (1em ~ 16px) und vergrößert den Spielraum nach oben zumindest etwas.
Ich kann mich halt nicht wirklich mit den Nachteilen von overlapping MQs anfreunden ...!
Gruß Gunther
Hallo!
wie umgehst du diese Problematik?
Vielleicht verstehe ich die Problematik nicht, aber was ist daran falsch, einfach »ein ganz bisschen« hinzuzufügen, was zu einem Pixel umgerechnet wird? Bspw.
@media only screen and (min-width: 50em) and (max-width: 90em) {
@media only screen and (min-width: 90.0625em) {
Oder runden die Browser das und wenden beide Regeln an, wenn der Viewport 90em breit ist?
So macht es Zurb Foundation bei seinen stacked MQs, die em verwenden. Scheint also zu funktionieren…?
Ausschnitt aus Foundation:
@media only screen and (min-width: 40.063em) and (max-width: 64em) {
@media only screen and (min-width: 64.063em) and (max-width: 90em) {
@media only screen and (min-width: 90.063em) and (max-width: 120em) {
usw.
Wenn ich das richtig verstehe, ist dein Einwand: Was ist, wenn 1em kleiner als 16px ist und 1/16em weniger als 1px ergibt?
Ja, erkenne ich als theoretisches Problem an… :) In der Praxis wird die Basisschriftgröße ohnehin in den allermeisten Fällen ignoriert und zur Vereinheitlichung body { font-size: 16px; } oder was auch immer gesetzt.
Grüße
Mathias
Hallo!
Wenn ich das richtig verstehe, ist dein Einwand: Was ist, wenn 1em kleiner als 16px ist und 1/16em weniger als 1px ergibt?
Ja, genau das ist das "Problem", bzw. die "Unzulänglichkeit" bei diesem Ansatz.
Gehen wir mal davon aus, dass ein User, sofern er die Basis-Schriftgröße ändert, diese vergrößert (also > 16px).
Dann tritt diese "Lücke" auf, wenn die Basis-Schriftgröße > 24px ist. Bis dahin sollte es mit dem 1/16px (0.0625em) Wert noch passen.
Ja, erkenne ich als theoretisches Problem an… :) In der Praxis wird die Basisschriftgröße ohnehin in den allermeisten Fällen ignoriert und zur Vereinheitlichung
body { font-size: 16px; }oder was auch immer gesetzt.
Media Queries interessieren sich aber nicht dafür, was ein Autor in seinem CSS für eine Schriftgröße (für welches Element auch immer) angibt.
Und außerdem verwendet man doch gerade deshalb MQs mit 'em', um die vom User gewählte Basis-Schriftgröße zu respektieren, und dabei gleichzeitig ein "intaktes" Layout zu gewährleisten.
Aktuell kann man diese "potentiell mögliche Lücke" nur dadurch vermeiden, dass man eben nur overlapping MQs verwendet.
Mögliche "Lösungen" für das Problem gäbe es viele ...!
Die einfachste wäre imho, wenn man 'calc()' in MQs verwenden könnte.
Gruß Gunther
Hallo,
Dann tritt diese "Lücke" auf, wenn die Basis-Schriftgröße > 24px ist. Bis dahin sollte es mit dem 1/16px (0.0625em) Wert noch passen.
Ah, okay, verstehe! Darauf war ich hier auch gekommen:
https://forum.selfhtml.org/?t=218062&m=1500286
(Sorry, falls euch beiden das alles schon klar war und ich wiederhole, was ihr schon wusstet und gesagt habt… ich hatte mich damit noch nicht beschäftigt. ;))
Mathias
Hallo Mathias!
(Sorry, falls euch beiden das alles schon klar war und ich wiederhole, was ihr schon wusstet und gesagt habt… ich hatte mich damit noch nicht beschäftigt. ;))
Kein Problem ...! ;-)
Aber wir hatten das Thema schon mal ..., siehe http://forum.de.selfhtml.org/archiv/2013/4/t213597/#m1460459
Du warst ja derjenige, der mich zu der Überzeugung gebracht hat, dass man damit "leben" kann! :-P
Gruß Gunther
@@Gunther:
nuqneH
Die einfachste wäre imho, wenn man 'calc()' in MQs verwenden könnte.
Weitaus einfacher, wenn man (schon) 'not' in MQs verwenden könnte:
@media not (min-width: 30em) {…}
@media (min-width: 30em) and not (min-width: 60em) {…}
@media (min-width: 60em) and not (min-width: 90em) {…}
@media (min-width: 90em) {…}
Qapla'
@@Gunnar:
nuqneH
Die einfachste wäre imho, wenn man 'calc()' in MQs verwenden könnte.
Weitaus einfacher, wenn man (schon) 'not' in MQs verwenden könnte:
@media not (min-width: 30em) {…}
@media (min-width: 30em) and not (min-width: 60em) {…}
@media (min-width: 60em) and not (min-width: 90em) {…}
@media (min-width: 90em) {…}
Ob das "weitaus einfacher" ist, sei mal dahingestellt ...!
Aber ich finde
~~~css
@media (min-width: 30em) and (max-width: calc(60em - 1px)) {…}
@media (min-width: 60em) and (max-width: calc(90em - 1px)) {…}
zumindest "intuitiver" (da ich weiterhin min- und max-width in meiner Query stehen habe).
Außerdem gibt es calc() Support ja bereits in vielen Browsern.
Die Browserhersteller bräuchten es ja bloß implementieren (und ggf. müsste man die Spec anpassen/ ändern).
Gruß Gunther
@@Gunther:
nuqneH
Aber ich finde
@media (min-width: 30em) and (max-width: calc(60em - 1px)) {…}
@media (min-width: 60em) and (max-width: calc(90em - 1px)) {…}
> zumindest "intuitiver" (da ich weiterhin min- und max-width in meiner Query stehen habe).
Ich finde `min-width`/`not min-width` nicht weniger intuitiv als `min-width`/`max-width`.
Berechnungen à la `calc(60em - 1px)` in MQs hingegen finde ich gar nicht intuitiv.
> Außerdem gibt es calc() Support ja bereits in vielen Browsern.
> Die Browserhersteller bräuchten es ja bloß implementieren
Das gilt für `not` innerhalb von MQs genauso.
> (und ggf. müsste man die Spec anpassen/ ändern).
Das ist für `not` bereits geschehen (WD Level 4).
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
@@Gunnar:
nuqneH
Aber ich finde
@media (min-width: 30em) and (max-width: calc(60em - 1px)) {…}
@media (min-width: 60em) and (max-width: calc(90em - 1px)) {…}
> > zumindest "intuitiver" (da ich weiterhin min- und max-width in meiner Query stehen habe).
>
> Ich finde `min-width`/`not min-width` nicht weniger intuitiv als `min-width`/`max-width`.
>
> Berechnungen à la `calc(60em - 1px)` in MQs hingegen finde ich gar nicht intuitiv.
Geschmackssache ...! :-P
> > Außerdem gibt es calc() Support ja bereits in vielen Browsern.
> > Die Browserhersteller bräuchten es ja bloß implementieren
>
> Das gilt für `not` innerhalb von MQs genauso.
Ja, nur dass das nach der bisherigen Spec\_so\_nicht funktioniert/ vorgesehen ist!
Hier bedarf es also erstens der Änderung in einer neuen Version der Spec, plus deren Implementierung in den Browsern.
> > (und ggf. müsste man die Spec anpassen/ ändern).
>
> Das ist für `not` bereits geschehen (WD Level 4).
Ja, schon klar.
Aber da die bisher noch nirgendwo implementiert ist, nutzt das rein gar nichts!
Und meine Aussage (extra in Klammern) bezog sich auf:
"Properties may accept more complex values, e.g., calculations that involve several other values. Media features only accept single values: one keyword, one number, or a number with a unit identifier. (The only exceptions are the ‘aspect-ratio’ and ‘device-aspect-ratio’ media features.) "
(Quelle: <http://www.w3.org/TR/css3-mediaqueries/#media1>)
Weil ich nicht beurteilen kann, ob ein Ausdruck in 'calc()' mit "one number, or a number with a unit identifier" vereinbar ist (laut Spec).
Von daher hielte ich eine entsprechende Umsetzung dieser Variante für schneller möglich, als die Implementierung der WD Level 4.
Gruß Gunther
Hallo,
Ich finde
min-width/not min-widthnicht weniger intuitiv alsmin-width/max-width.
Ich finde min-width und max-width an sich scheiße, so! ;)
Keine Ahnung, warum man da eine Logik erfinden musste, mit der sich vieles nicht präzise ausdrücken lässt. Die Syntax von Programmiersprachen ist bereits gut genug:
if (media is screen and 30em <= width < 60em) {
…
}
:)
Das ist für
notbereits geschehen (WD Level 4).
Ah, danke, gut zu wissen!
only screen and not Mathias
@@molily:
nuqneH
Die Syntax von Programmiersprachen ist bereits gut genug:
if (media is screen and 30em <= width < 60em) {
Man wollte wohl keine Vergleichsoperatoren in CSS einführen.
Qapla'
@@Gunnar:
nuqneH
Die Syntax von Programmiersprachen ist bereits gut genug:
if (media is screen and 30em <= width < 60em) {Man wollte wohl keine Vergleichsoperatoren in CSS einführen.
Wegen '>' leuchtet mir das ja noch ein.
Aber es hätte ja auch genügend andere Wege gegeben, dasselbe zu ermöglichen.
Und zumindest 'if - else' wären hilfreich.
Dass die Einführung von @supports viel viel zu spät erfolgt ist, darüber brauchen wir ja (hoffentlich) nicht diskutieren! ;-)
Gruß Gunther
Hallo,
Dank deiner freundlichen Unterstützung kann ich jetzt erstmal weiter basteln (u.a. möchte ich "benannte" Breakpoints verwenden können, die ich in einer Map speichere/ gespeichert sind).
Ich definiere projektweit ein paar benannte MQ-Mixins für verschiedene Viewport-Größen (extra small, small, medium, large), ähnlich Bootstrap:
https://github.com/twbs/bootstrap-sass/blob/master/assets/stylesheets/bootstrap/_variables.scss#L267-L303
http://pastebin.com/2Unn7RAp
Damit komme ich meistens aus.
PS: Hast du evt. auch noch einen Tipp bezüglich eines Mixins für 'resolution', bzw. 'min-device-pixel-ratio'?
Den verwende ich:
@mixin two-dppx()
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi), (min-resolution: 2dppx)
@content
Man kann natürlich beliebige weitere Device-Pixel-Ratios unterstützen, aber mich interessieren derzeit nur 1 (default) und 2 (mit obiger MQ).
Mathias
Hallo Mathias!
PS: Hast du evt. auch noch einen Tipp bezüglich eines Mixins für 'resolution', bzw. 'min-device-pixel-ratio'?
Den verwende ich:
@mixin two-dppx()
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi), (min-resolution: 2dppx)
@content
Nur fürs Archiv:
~~~css
@mixin two-dppx {
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi), (min-resolution: 2dppx) {
@content
}
}
Man kann natürlich beliebige weitere Device-Pixel-Ratios unterstützen, aber mich interessieren derzeit nur 1 (default) und 2 (mit obiger MQ).
Ja, mal abgesehen davon, dass es durchaus auch noch andere (relevante) Auflösungen gibt, aber wie sieht es denn mit der Kombination mit anderen media features aus?
Und was ist mit den anderen Vendor Prefixes? Sind die nicht mehr nötig (sprich, nicht mehr relevant)?
@media
only screen and (-webkit-min-device-pixel-ratio: 2) and (min-width: 60em),
only screen and ( min--moz-device-pixel-ratio: 2) and (min-width: 60em),
only screen and ( -o-min-device-pixel-ratio: 2/1) and (min-width: 60em),
only screen and ( min-device-pixel-ratio: 2) and (min-width: 60em),
only screen and ( min-resolution: 192dpi) and (min-width: 60em),
only screen and ( min-resolution: 2dppx) and (min-width: 60em) {
/* Medium screen, retina, stuff to override above media query */
}
Gruß Gunther
@media
only screen and (-webkit-min-device-pixel-ratio: 2) and (min-width: 60em),
Ist weiterhin nötig z.B. für Safari 7.0.
only screen and ( min--moz-device-pixel-ratio: 2) and (min-width: 60em),
Firefox unterstützt min-resolution ab Version 16 (Oktober 2012). Halte ich daher für unnötig.
Aber warum die ständige Wiederholung von »only screen«? Diesen only-Quatsch hat man ohnehin nur für »older user agents« erfunden. Ich weiß gar nicht mehr für welche. Ich fahre sehr gut ohne diesen »only screen«.
only screen and ( -o-min-device-pixel-ratio: 2/1) and (min-width: 60em),
Opera (Presto) ist tot. Diese letzte Opera-Presto-Version 12.16 unterstützt aber auch min-resolution.
only screen and ( min-device-pixel-ratio: 2) and (min-width: 60em),
Ich wüsste keinen Browser, der das unterstützt, aber kein min-resolution.
only screen and ( min-resolution: 192dpi) and (min-width: 60em),
min-resolution mit dpi-Wert Unterstützt IE ab Version 9.
only screen and ( min-resolution: 2dppx) and (min-width: 60em) {
Das ist die empfohlene und standardisierte Schreibweise, sollte also auf jeden Fall drin sein. Wird unterstützt von Firefox und Chrome.
Übrigens sehe ich wenig Sinn darin, in Media Queries für Device-Pixel-Ratio auch noch die Viewport-Breite einzubeziehen. Das sind zwei Dinge, die erst einmal wenig miteinander zu tun haben. Natürlich muss man sie ggf. kombinieren. Beispiel: Kleine Viewports mit 1dppx bekommen ein 200px-Foto, kleine Viewports mit 2dppx bekommen ein 400px-Foto, große Viewports mit 1dppx bekommen ein 600px-Foto, große Viewports mit 2dppx ein 1200px-Foto. (Ob man das wirklich so machen würde, ist eine andere Frage.)
Mathias
@@Gunnar Bittersmann:
nuqneH
Wozu brauchst du das Mixin eigentlich? Für
@include mq("(min-width: 1em)", "(max-width: 2em)")
kannst du doch auch gleich ``@media (min-width: 1em) and (max-width: 2em){:.language-css} schreiben.
Qapla'
@@Gunnar:
nuqneH
Wozu brauchst du das Mixin eigentlich? Für
`@include mq("(min-width: 1em)", "(max-width: 2em)")`{:.language-css}kannst du doch auch gleich ``@media (min-width: 1em) and (max-width: 2em)
{:.language-css}schreiben.
Stimmt! ;-)
Das wäre nun wirklich nicht besonders hilfreich.
Eigentlich wollte ich zum einen mal meine Kenntnisse etwas auffrischen und erweitern, und zum anderen habe ich mir jetzt ein Mixin "gebastelt" samt zweier Helferfunktionen, was mir die Arbeit erleichtert.
Ich verwende zwei Maps (in einer Config-Datei):
Die eine beinhaltet die eigentlichen Breakpoints (egal mit welcher Einheit),
die andere "benannte Bereiche"
Und da ich ja wie bereits erwähnt überwiegend stacking MQs verwende, muss mein Mixin also den entsprechenden 'max-width' Wert berechnen.
Beispiele:
@include mq(bp4) {...}
ergibt:
@media screen and (min-width: 30em) and (max-width: 37.45em) {...}
@include mq(bp4, bp8) {...}
ergibt:
@media screen and (min-width: 30em) and (max-width: 47.95em) {...}
@include mq((media, print), (min, bp8)) {...}
ergibt:
@media print and (min-width: 48em) {...}
@include mq((bp4, bp8), (orient, landscape)) {...}
ergibt:
@media screen and (min-width: 30em) and (max-width: 47.95em) and (orientation: landscape) {...}
@include mq(only-medium) {...}
ergibt:
@media screen and (min-width: 48em) and (max-width: 99.95em) {...}
Ich wollte mir u.a. auch ein "Hintertürchen" offen halten, falls ich doch mal auf overlapping MQs umsteige ...! :-P
Gruß Gunther