Mit all dem Gerede in letzter Zeit, endlich CSS Grid verwenden zu können, brachte es mich auf die Idee: Welche anderen erstaunlichen CSS-Funktionen kann ich jetzt nutzen? CSS-Variablen war die eine, die sofort in den Sinn kam.
Es ist schon eine Weile her, seit ich etwas über CSS-Variablen gehört habe und es bringt ein ganz neues Toolset und eine neue Denkweise für die Front-End-Entwicklung, die mich begeistert.
CSS-Variablen sind seit einigen Jahren im Umlauf, scheinen aber nicht weit verbreitet zu sein. Mit der Popularität von Pre-Prozessoren wie Sass haben Frontend-Entwickler dieses Variable Juckreiz vor langer Zeit gekratzt.
Ich wurde etwa 2014 von CSS-Variablen begeistert und seitdem bin ich in meine Interessensphäre eingetaucht. Ich überlege mir gerade, sie in Produktionsstandorte zu bringen, und ich werde Ihnen zeigen, wie einfach und einfach sie zu verwenden sind.
Das Deklarieren der benutzerdefinierten Eigenschaft ist einfach: Wir müssen nur die gewünschte Eigenschaft erstellen und zwei Bindestriche an den Anfang davon anfügen. Diese können überall deklariert werden, aber sie müssen hinzugefügt werden: root scheint im Moment ein guter Ansatz zu sein.
--my-reusable-value: 20px;Die Verwendung der Eigenschaft ist auch ziemlich einfach. Wir greifen auf sie über die Funktion var () zu und verwenden die oben angegebene Eigenschaft.
padding: var(--my-reusable-value);Ist das nicht einfach und herrlich?
CSS-Variablen sind einfach zu bedienen und einfach zu merken. Die größte Herausforderung bei CSS-Variablen (wie bei den meisten CSS) besteht darin, den richtigen Zeitpunkt und Ort zu kennen, an dem sie verwendet werden können. Sie willkürlich zu werfen, ist ein sicherer Weg, um ein Chaos eines Stylesheets zu erzeugen, und mit diesen Variablen, die in Debugging geworfen werden, wird wahrscheinlich schwieriger werden.
Angemessene Anwendungsfälle und Strategien für ihre Verwendung sollten in Betracht gezogen werden, und hier sollte sich der Großteil Ihrer Bemühungen konzentrieren.
Im folgenden Beispiel zeige ich Ihnen ein grundlegendes Beispiel dafür, wie ich derzeit eine reaktionsfähige Komponente mit Sass-Variablen erstelle. Dann zeige ich Ihnen, wie es mit CSS-Variablen so verbessert werden kann, wie es mit einem Pre-Prozessor nicht möglich ist. Dies ist ein spezifischer Anwendungsfall, der nicht für jede Art der Variablenverwendung gilt, sondern zeigt, wie CSS-Variablen anders verwendet werden können.
Sieh den Stift CSS-Variablen - reaktionsfähiger Anwendungsfall ohne CSS-Variablen von Adam Hughes ( @verlor mein Gehirn ) auf CodePen .
Bei der Verwendung von Sass gibt es ein paar verschiedene Methoden, die ich ausprobiert habe. Meine aktuelle Version ist das Platzieren von Medienabfragen innerhalb der CSS-Blöcke, die ich ändern möchte. Hier kann ich eine Variable, Standard-CSS, Mixin oder eine Erweiterung verwenden, um dieses Element zu modifizieren, ohne die Stile für die Komponente überall zu verstreuen.
Ein Problem damit ist, mehrere Medienabfragen und viele Variablen zu haben, die irgendwie verwandt aber nicht sind. Ich könnte Maps für die Variablen verwenden, die mehr Organisation ergeben würden, aber ich denke, das Hauptproblem ist, dass wir mehrere Variablen verwenden, um eine Eigenschaft zu definieren. Das fühlt sich einfach falsch an.
Sass-Variablen werden im Voraus verwendet, was bedeutet, dass wir jede Art und Weise planen müssen, wie wir sie verwenden werden. Sie erleichtern die Entwicklung, bieten uns aber technisch keine neuen Superkräfte.
Sieh den Stift CSS-Variablen - reaktionsfähiger Anwendungsfall von Adam Hughes ( @verlor mein Gehirn ) auf CodePen .
CSS-Variablen müssen nicht im Voraus deklariert werden, sie sind dynamisch. Dies ist sehr nützlich. Wir können jetzt Variablen von überall und in bestimmten Kontexten, wie Medienabfragen, bedingt ändern.
Durch die Verwendung unserer Media-Query-Styles können wir die Menge an Medienanfragen reduzieren, die für responsives Styling verstreut sind. Es bietet auch eine sehr schöne und saubere Möglichkeit, allgemeine Abstände und Typografie in verschiedenen Formaten zu sehen.
Ich denke, Responsive Designs und Themes sind zwei ausgezeichnete Anwendungsfälle für CSS-Variablen, aber es gibt so viele Möglichkeiten.
Sass Variablen und CSS Variablen sind zwei verschiedene Bestien mit jeweils eigenen Pro's und Con's.
Aufgrund der Popularität von Sass und der mehr programmatischen Natur von Sass haben sich im Laufe der Zeit tiefgreifendere Organisationsmuster herausgebildet. Ich mag besonders Sass-Maps und kombiniere ähnliche Typvariablen in die Maps. Farben, Größen und Shortcuts für Pfade scheinen beliebte Optionen für die Aufnahme in Karten zu sein.
Aufgrund der relativ geringen Verwendung von CSS-Variablen müssen sich die Best Practices noch entwickeln. Maps und Arrays sind in CSS nicht in der gleichen Weise möglich, daher müssen diese neuen Organisationsmuster innovativ sein und die Probleme auf eine andere Art und Weise lösen als Sass.
CSS-Variablen werden zur Laufzeit vom Browser dynamisch gehandhabt, während Sass-Variablen verwendet werden, wenn das CSS kompiliert wird.
Dies ist das zentrale Verkaufsargument von CSS-Variablen für mich. Es wird interessant sein, zu sehen, wie die Leute dieses Feature im Laufe der Zeit nutzen und ob es seinem Potenzial gerecht wird.
Ich persönlich bin der Meinung, dass je mehr Dinge wir aus Webpack , Gulp und was auch immer-neu-Framework-out-jetzt entfernen können, desto besser. Mit interessanten neuen Browserfunktionen müssen wir uns nicht auf Kompilierungs- und JavaScript-Frameworks verlassen, um Dinge zu tun, die nach Meinung von Entwicklern wichtig sind. Ich würde vermuten, dass ein hoher Prozentsatz von Frontend-Entwicklern Variablen in ihrem CSS auf die eine oder andere Weise verwendet, so dass jeder, der dieses Kernfeature benutzt, wie eine vernünftige Sache erscheint. Es bedeutet eine Sache weniger im Build-Schritt (von der ich denke, dass wir uns alle einig sind, wird heutzutage ziemlich immens) und mehr Konsistenz im Web.
Die Unterstützung sieht mit einer eklatanten Ausnahme bemerkenswert gut aus: IE 11. Die meisten modernen Browser unterstützen CSS-Variablen, wobei Edge einige Bugs aufweist.
Mit 78,11% ist dies höher als CSS Grid (zum Zeitpunkt des Schreibens), aber IE11-Unterstützung könnte ein Problem sein.
Ich denke, die Zeit ist jetzt. Die IE11-Unterstützung wird nicht besser werden, und wir wissen von früheren Versionen von Windows, dass es einige Leute braucht, bis sie ein Upgrade brauchen. Aber die Unterstützung über moderne Browser ist großartig, was bedeutet, dass wir auf CSS-Variablen schauen und mit den Möglichkeiten experimentieren sollten.
Das bedeutet nicht, dass wir unsere Verantwortung für die Unterstützung älterer Browser nicht vergessen sollten. Ein grundlegendes Fallback-System, das für ältere Browser ein Unterstützungs-Tag oder sogar ein Polyfill verwendet, sollte in Betracht gezogen werden, umso mehr, wenn Ihre tatsächliche Websitenutzung gegenüber älteren Browsern viel stärker verzerrt ist.
Es ist eine aufregende Zeit für die Entwicklung des Frontends, und ich kann es kaum erwarten, mehr dieser Technologien in meinen Produktionsstätten einzusetzen.