Ich liebe es, meine @media query Breakpoints zu verschachteln. Das ist für mich vielleicht das wichtigste Feature von Sass. Vielleicht wähle ich eine Methode und mache es so
.element {
display: grid;
grid-template-columns: 100px 1fr;
@include breakpoint(baby-bear) {
display: block;
}
}
Das ist ganz einfach. Aber was ist, wenn mein Element mehrere Unterelemente hat und der Breakpoint diese ebenfalls betrifft? Es gibt verschiedene Ansätze, und ich bin mir nie ganz sicher, welchen ich verfolgen sollte.
Ich könnte den Breakpoint für jedes Kind duplizieren
.parent {
@include breakpoint(desktop) {
}
.child {
@include breakpoint(desktop) {
}
}
.child-2 {
@include breakpoint(desktop) {
}
}
}
Der kompilierte CSS-Code sieht dann etwa so aus
@media screen and (min-width: 700px) {
.parent {
}
}
@media screen and (min-width: 700px) {
.parent .child {
}
}
@media screen and (min-width: 700px) {
.parent .child-2 {
}
}
Oder ich könnte die Kinder unter dem ersten verschachtelten Breakpoint duplizieren
.parent {
@include breakpoint(desktop) {
.child {
}
.child-2 {
}
}
.child {
}
.child-2 {
}
}
Das führt zu
@media screen and (min-width: 700px) {
.parent .child {
}
.parent .child-2 {
}
}
.parent .child {
}
.parent .child-2 {
}
Oder ich könnte eine Kombination aus beidem tun. Keiner von beiden fühlt sich wegen der Duplizierung besonders gut an, aber ich bin mir nicht sicher, ob es hier eine perfekte Antwort gibt. Ich neige eher zum Duplizieren der Media Query, da dies weniger fehleranfällig zu sein scheint als das Duplizieren von Selektoren.
Ich mache den ersten Ansatz und verlasse mich auf ein Build-Tool, um Media Queries zu kombinieren (PostCSS-Plugins)
Welches PostCSS-Plugin ist das?
Ich stimme zu, ich bin mir nicht sicher, ob es eine perfekte Antwort gibt. Ich versuche, die Anzahl der Media Queries zu minimieren, bin aber nicht konsequent.
Ich habe dasselbe Problem. Bei mir hängt es von der Anzahl der Änderungen und der Komplexität der Kindelemente ab. Bei komplexen Kindelementen verschachtle ich die Media Query im Kind. Wenn Sie nur einige Eigenschaften ändern müssen, gruppiere ich sie innerhalb einer Media Query.
Ich mache normalerweise (wenn Verschachtelung unvermeidlich ist) die erste Methode mit Duplizierung und optimiere das Ergebnis mit einem Post-Prozessor (PostCSS, Webpack-Loader usw.), um dieselben Media Queries zu einer einzigen zusammenzufassen. Auf diese Weise können Sie wiederverwendbare Blöcke schreiben und gleichzeitig die CSS-Datei nicht aufblähen ;)
Ich platziere sie immer noch am Ende der Datei, da es für mich einfacher ist zu sehen, wie sich das Modul als Ganzes bei einem bestimmten Breakpoint ändert. Es ist auch viel einfacher zu organisieren, wenn mehrere Breakpoints verwendet werden.
Module werden selten groß genug, um diesen Ansatz umständlich zu machen, und wenn Sie Ihr Projekt so organisieren, dass Breakpoints alle in die gleiche Richtung skalieren, ist es sehr einfach, Spaghetti-Code zu erkennen.
Diese Redundanz der Ausgabe hat mich schon immer gestört. Es wäre großartig, wenn der Prozessor die im Dokument wiederholten Media Queries erkennen und jede einmal am Ende setzen würde, um allen zugehörigen Inhalt darin zu verschieben.
Ich versuche normalerweise, den Breakpoint am höchststufigen Selektor zu haben, den er in diesem "Baum" beeinflussen könnte, und dann alle Kinder, die er beeinflusst, in diesen Breakpoint zu legen.
Es ist ein wenig fehleranfälliger, aber es macht auch sehr deutlich, was sich bei verschiedenen Breakpoints alles an einer Stelle ändert, anstatt jede einzelne Regel durchlesen zu müssen, wenn man etwas sucht, das bei einer nicht ganz richtig ist.
Sehr nützliches Gulp-Tool beim vielen Verschachteln: https://github.com/hail2u/node-css-mqpacker
Es geht also nur um den OUTPUT, richtig? Ich könnte verstehen, wie das Kombinieren der Media Queries in der Ausgabe Bytes spart, aber mein Verständnis ist, dass Gzip das vernachlässigbar macht und Browser geschwindigkeitsmäßig anscheinend keine Rolle spielen. Ich bin hauptsächlich an der Autorenerfahrung interessiert.
Es geht ein wenig um die Größe, aber hauptsächlich um die Autorenerfahrung, zumindest in unserem Fall. Bei viel Code wird das zweite Beispiel schnell mühsam zu verwalten, besonders bei viel Verschachtelung. Und wir sind auch der Meinung, dass das erste Beispiel klarer und leichter zu verstehen ist.
Das zweite, aber mit den Media Queries nach den Stilen, die sie verändern, z. B. das Letzte, bevor das Elternelement geschlossen wird.
Ich mag den ersten Ansatz sehr – es ist schön, alle Stile unter dem Selektor zu verschachteln, anstatt den Selektor innerhalb einer Media Query zu duplizieren. Dies ermöglicht es Ihnen, alle auf einen Selektor angewendeten CSS-Stile mit einem einzigen Blick zu verstehen.
Mein Verstand denkt in Bezug auf Selektoren: "Was macht dieser Selektor bei diesem und jenem Breakpoint?"
Im Gegensatz zu: "Lasst uns bei diesem und jenem Breakpoint sehen, ob der Selektor, den ich brauche, geändert wird."
Ich bin sicher, dass andere Leute anders denken.
Ich bin sicher, dass andere Leute anders denken.
Absolut! Für mich ist es genau umgekehrt – ich sehe es nach Bildschirmen, ein bisschen so, als ob @media ein eigenes CSS-Blatt öffnen würde, deshalb bevorzuge ich den zweiten Ansatz sehr: Ich würde es genau so schreiben, wenn ich den Code von Hand verfassen würde.
Ich bin bei dir Andy, so funktioniert mein Gehirn auch. Das ist eigentlich der Grund, warum ich diese Methode überhaupt anstelle von separaten SCSS-Stylesheets für jeden Breakpoint verwende – es war so schwer, all die Stile zu finden/zu verstehen, die auf einen bestimmten Selektor angewendet wurden, wenn sie verteilt waren.
Eine einfache Lösung ist die Verwendung des PostCSS-Plugins mq-packer.
Es bündelt Media Queries
Ich habe vor ein paar Stunden über dasselbe nachgedacht, also habe ich darüber nachgedacht, CSS- oder Sass-Variablen anstelle von verschachtelten Media Queries zu verwenden.
Für mich ist die zweite Option etwas leichter zu verstehen und bietet eine etwas bessere Lesbarkeit für einen neuen Entwickler, der sich schnell in das Projekt einarbeiten muss.
Es ist viel einfacher, einen bestimmten Stil für einen bestimmten Breakpoint zu finden, wenn nur ein einziger Breakpoint pro Komponente vorhanden ist.
Für kleine Anpassungen mag ich es, mehrere Media Queries zu verschachteln, wie folgt
Dies ermöglicht es Ihnen, einfach zu verfolgen, was geändert wird, ohne sich um die Klasse bewegen zu müssen und all die verschiedenen Media Queries zu betrachten.
Das kompiliert jedoch unordentlich
Glücklicherweise kümmert sich ein Minifier, der auf das Kombinieren von Media Queries eingestellt ist, darum
Für mich ziehe ich es vor, Variablen und
@mediaanstelle von Mixins zu verwendenEs gibt ein PostCSS-Plugin, um Media Queries zu kombinieren.
Ich verwende einen Mobile-First-Ansatz, style die grundlegenden Dinge zuerst und habe darunter einen "responsiven Abschnitt", in dem ich einige Layout-Überschreibungen vornehme. Das gibt mir die klarste Sicht auf die Kaskade. Man könnte sagen, große Bildschirme sind ein Feature!
Ich mag den ersten Ansatz, es ist wie zu sagen "ok, jetzt machst du das bei diesem Breakpoint".
Außerdem ist die Duplizierung kein Problem, wenn Sie Ihr CSS komprimieren.
Hey, in deinem letzten Beispiel. Die Kind-Div-Elemente überschreiben die CSS in der Media Query wegen der Kaskade –
Das mache ich genau so. Leichter zu verstehen, wenn man den Kontext hat.
Ich stimme definitiv zu, dass die Verschachtelung von Media Queries mit SCSS das wichtigste Merkmal der Syntax ist.
Ich persönlich wähle die Duplizierung der Media Queries in jedem Kind, da dies für mich am sinnvollsten ist. Alle Stile für dieses Element sind an derselben Stelle. Ich kann das Styling nicht vergessen, das halb im oberen Teil der Datei getrennt ist.
In diesem Zusammenhang versuche ich mich in letzter Zeit zu zwingen, überhaupt keine verschachtelten Kindregeln zu schreiben. Da ich festgestellt habe, dass dies zu einer erhöhten Spezifität führen kann, die subtiler ist, und ich ziemlich tiefe Selektoren im kompilierten Code erhalten kann, die mir später Probleme bereiten könnten. Die Selektoren flach zu halten, wie bei Vanilla CSS, macht diese erhöhte Spezifität für mich viel bemerkbarer, da ich diese Eltern-Kind-Selektoren tatsächlich schreibe und es meine Denkprozesse auslöst, um zu prüfen, ob ich diese Verschachtelung tatsächlich benötige.
Ich mag den zweiten Ansatz, da er leichter zu verwalten ist und weniger Duplizierung aufweist. Außerdem können sie in Zukunft leicht in separate Dateien verschoben werden, basierend auf Bildschirmgrößen.
Ich neige dazu, den ersten Weg zu gehen, den Sie erwähnt haben. Erzeugt leider viele duplizierte Media Queries. Ich habe die verschiedenen Gulp Media Query Combiner ausprobiert, aber sie scheinen gemischte Ergebnisse für mich zu liefern. Hat jemand diese schon ausprobiert? Wie zum Beispiel gulp-combine-mq?
Ich versuche wirklich, Verschachtelungen in Sass so weit wie möglich zu vermeiden, daher bleibe ich beim ersten Ansatz. Dann folge ich mit Selektoren mit niedriger Spezifität und wende die Breakpoints danach auf sie an. Ich denke, das bereinigt den Sass und emuliert auch, wie der verarbeitete CSS-Code aussehen wird, wobei beide Anliegen beim Schreiben berücksichtigt werden.
Ich wähle normalerweise die zweite Option nur, wenn es viele Änderungen an diesem einzelnen Breakpoint gibt.
Normalerweise erstelle ich einen Breakpoint, wenn das Design passt, nicht nur eine Reihe von Breakpoints. Also schreibe ich normalerweise Code wie Option #1.
Ich habe früher die erste Methode verwendet, aber bei großen Projekten (mit vielen SCSS-Includes) war die kompilierte CSS-Datei in KBytes so viel größer.
Ich fand es nützlich, alle @media-Regeln am Ende jeder SCSS-Datei zu belassen, die ich verwende. Wenn ich also ein .info-box-Element in seiner _info-box.scss-Datei habe, habe ich normalerweise alle @media's direkt unter dem .info-box {} Block.
So weiß ich, wo ich alles finden kann. Und jedes Element/jede Komponente hat seine eigene SCSS-Datei mit allen Breakpoint-Informationen.
Persönlich verwende ich das Kombinier-MQ-Plugin und füge Breakpoints unter den Kindern hinzu. Da ich Mobile-First entwickle, ist es leichter zu lesen und zu verstehen.
https://www.npmjs.com/package/combine-mq
Ich verschachtele Selektoren nur noch selten, aber wenn ich es tue, platziere ich die Media Query trotzdem normalerweise direkt im Selektor. Dies hält jeden Selektor eigenständig und kümmert sich um seine eigene Positionierung. Selbst ohne Selektoren zu verschachteln, ist der Ansatz im Wesentlichen derselbe, da die Media Queries in den Selektorkörper gelangen.
Jedes Projekt kann anders sein, in meiner Situation werden Designs immer mit harten Breakpoints im Hinterkopf erstellt. Mit diesem Wissen möchte ich eine mehrstufige Ordnerstruktur für Komponenten, Seiten, strukturelle Vorlagen usw. beibehalten. Es gibt einen Ordner für globale Elemente und Unterordner für Projekte, die dieselben Assets teilen.
Mit diesem Wissen habe ich eine Hauptkonstruktionsdatei, die dann gerätespezifische Breakpoints (Ihre typischen Bildschirmgrößen) importiert, die alle Komponenten, Layout-Elemente usw. in jeder Gruppe umfassen. Innerhalb jedes Komponentenordners befindet sich eine Anordnung von Dateien, die nach Breite definiert sind, wo mehrere Entwickler auf dieselbe Datei zugreifen können und es keine Verwirrung gibt, wo Breakpoints platziert werden sollen, da diese Entscheidung durch die Architektur der Dateien getroffen wird. Typischerweise gibt es keine weiteren Unter-Breakpoints, obwohl einige Retina-Queries sich dort einschleichen mögen. Es ist etwas umständlicher einzurichten mit all den Dateien und Importen, aber diese Struktur hat zu vielen großen, schnell entwickelten Projekten mit großem Erfolg geführt.
Interessant! Ich mache auch den ersten Ansatz. Ich denke, es ist "vernünftiger", alle Stile, die ein Element beeinflussen, so weit wie möglich zusammenzufassen.
Ich verschachtele keine Selektoren.
.parent {
@include breakpoint(full-hd) {
// …
}
}
.parent__child-1 {
@include breakpoint(full-hd) {
// …
}
}
.parent__child-2 {
@include breakpoint(full-hd) {
// …
}
}
// ————————————–
// Und ich verwende Pseudo-Striche und Überschriftenkommentare zur Klarheit
Ich bevorzuge immer Ansatz eins. Er ist für mich besser und lesbarer :)
Ich gehe immer mit #1 (oder zumindest 99% der Zeit). Alles passiert innerhalb dieses Selektors.
Ich bevorzuge den ersten Stil sehr: Definiere die Basisstile des Selektors, verschachtele dann die Anpassungen für jeden Breakpoint darunter. Das behält ALLE Stile für einen Selektor an einem Ort, was es sehr einfach macht, zu sehen, ob und wie sie bei bestimmten Breakpoints geändert werden.
Es ist auch sauberer und weniger fehleranfällig, da Sie jeden Selektor nur einmal definieren. Wenn Sie den entgegengesetzten Ansatz verwenden, bei dem Sie einen Satz von Media Queries definieren und dann die Selektoren darin duplizieren, ist es einfacher, einen Fehler zu machen, ohne es zu merken (z. B.
.parent .childunter einer Media Query zu schreiben, aber.parent.childunter einer anderen).Das Ergebnis ist mir egal, da sowieso alles minifiziert/verkettet wird. Ich ziehe lesbarere und weniger fehleranfällige Dinge für die Autorenerfahrung vor.
Oder Sie könnten https://github.com/hail2u/node-css-mqpacker verwenden und es vergessen.