Die CSS-Verschachtelung macht wieder die Runde. Erinnern Sie sich, Anfang des Jahres, als Adam und Miriam drei Syntaxoptionen zur Abstimmung stellten? Diese Ergebnisse wurden ausgewertet und es war nicht einmal knapp.
Nun gibt es eine weitere Möglichkeit, Einfluss auf die Zukunft der Verschachtelung zu nehmen, diesmal im WebKit-Blog. Die Ergebnisse der Umfrage von Adam und Miriam lösten weitere Diskussionen aus und zwei weitere Ideen wurden in den Ring geworfen. Diese neue Umfrage ermöglicht es Ihnen, aus allen fünf Optionen zu wählen.
Jen Simmons hat eine umfassende Übersicht dieser Optionen zusammengestellt, einschließlich einer Auffrischung der Verschachtelung, Details darüber, wie wir zu den fünf Optionen gekommen sind, und zahlreichen Beispielen, die die Optionen in verschiedenen Anwendungsfällen zeigen. Geben wir die harte Arbeit, die hier geleistet wird, zurück, indem wir an dieser kurzen Umfrage mit einer Frage teilnehmen.
Ich habe gerade versucht abzustimmen, aber ich sehe keine Möglichkeit dazu, nur die bisherigen Ergebnisse. Vielleicht wurde sie bereits geschlossen? Es scheint aber keine sehr lange Zeit zu sein, um die Umfrage offen zu halten.
Es ist schade, denn ich hätte mich für Option Nr. 5 entschieden, die derzeit nicht die beliebteste ist. Ich mag die Einfachheit von Nr. 3 und ihre Ähnlichkeit mit SASS, aber das Potenzial für seltsame Fehler und Randfälle macht mich ein wenig nervös. Es geht schließlich darum, das Richtige für die Zukunft von CSS zu wählen.
Option Nr. 4 lässt mein Gehirn einfach schmerzen, also bin ich froh, dass sie zumindest nicht die beliebteste ist.
Ich sehe, dass Jen die drei ursprünglichen Optionen erwähnt (1, 2 und 3), von denen die dritte „verschachtelte Anweisungen in Klammern einschloss“. Diese Option sehe ich in diesem Artikel nicht verwendet. Was ist damit los? Verpasse ich etwas?
Ich glaube nicht, dass Entwickler über diese Dinge entscheiden sollten, nebenbei bemerkt. Und ja, ich glaube das wegen des aktuellen Gewinners, Option 3. Die Syntax zwingt Sie manchmal zur Verwendung von
:is(), was meiner Meinung nach so unraffiniert ist, wie man nur sein kann, und ehrlich gesagt eine totale Schande für die Sprache. Eleganz wurde über Bord geworfen, während dasa:b-Problem gelöst werden könnte, indem man darauf schaut, was danach kommt – ein Semikolon (es ist eine Regel) oder eine Klammer (es ist ein Selektor und wir verschachteln).Aber vielleicht spricht hier meine Naivität, ich habe an diesen Diskussionen noch nie teilgenommen und vielleicht übersehe ich auch ein Detail in meinem Beispiel.
Ich denke, die Absicht ist weniger, dass Entwickler entscheiden, sondern mehr, was Jen am Ende sagt
Ich verstehe nicht, warum sie sagen: In vielen der folgenden Beispiele ist das & optional.
Es gibt kein Beispiel mit „.foo.bar“.
Aber Option Nr. 3 ist in Ordnung – glaube ich.
Ich konnte auch keine Möglichkeit zum Abstimmen sehen.
Wenn ich könnte, würde ich dafür stimmen, gar keine verschachtelte CSS zu haben. Jedes Beispiel ist mit der unverschachtelten CSS einfacher zu lesen, zu kopieren und zu debuggen. Ich sage, überlassen Sie das Verschachteln Prä- oder Post-Prozessoren, damit es optional ist.
Ich verstehe nicht, warum das überhaupt zur Abstimmung gestellt werden musste. Verwenden Sie einfach den gleichen Verschachtelungsstil wie Less und Sass seit Jahren, es ist das, was Frontend-Entwickler bereits kennen und erwarten.
Ich bin froh, dass das reguläre @nest gewonnen hat.
Sie sollten Jims Beitrag vielleicht genauer lesen, denn er erklärt, warum wir nicht die gleiche Syntax wie Sass oder Less verwenden können.
Was mich am meisten verblüfft, ist, warum die Leute eine Syntax wählen, die buchstäblich die gleiche wie SASS ist, als ob man das wählen würde, dann einfach den Präprozessor verwenden würde.
@nestfühlt sich meiner Meinung nach viel konsistenter mit der CSS-Syntax an, oder vielleicht einfach keine Verschachtelung einführen.CSS muss nicht den Spuren der Präprozessoren folgen und stattdessen nur darauf abzielen, sich bei Funktionen zu verbessern, die außerhalb ihrer Kontrolle liegen.
Ich verstehe nicht, warum Option 4 die wenigsten Stimmen erhalten hat. Sie ist viel sauberer als Option 5 und hat nicht die Probleme mit der Wahloption, die kein Buchstabensymbol als erstes Zeichen eines Selektors zulässt (diese :is()-Umgehung ist kaum elegant).
Ich mag das besonders
Das funktioniert auch gut