Lassen Sie uns eine CSS-Utility-Bibliothek als Stylesheet definieren, das viele Klassen enthält, die für kleine, einmalige Dinge verwendet werden können. Wie Klassen zur Anpassung von Rändern oder Abständen. Klassen zur Festlegung von Farben. Klassen zur Festlegung spezifischer Layout-Eigenschaften. Klassen für die Größenbestimmung. Utility-Bibliotheken können diese Dinge auf unterschiedliche Weise angehen, scheinen aber diese Idee zu teilen. Dies bringt im Wesentlichen das Styling auf die HTML-Ebene und nicht auf die CSS-Ebene. Das Stylesheet wird zu einer Entwicklungsabhängigkeit, die Sie nicht wirklich anfassen müssen.
Nur eine Utility-Bibliothek verwenden vs. Utilities einstreuen
Eine Möglichkeit, eine Utility-Bibliothek wie die folgenden als Ergänzung zu allem anderen, was Sie mit CSS tun, zu verwenden. Diese Projekte haben tendenziell unterschiedliche Philosophien und ermutigen dies vielleicht nicht immer, aber natürlich können Sie tun, was Sie wollen. Man könnte das als Einstreuen einer Utility-Bibliothek bezeichnen, und Sie könnten mit HTML enden wie
<div class="module padding-2">
<h2 class="section-header color-primary">Tweener :(</h2>
</div>
Verzeihen Sie ein wenig Meinungsäußerung hier, aber für mich scheint dies etwas zu sein, das sich *im Moment* gut anfühlt und dann später bedauerlich ist. Anstatt dass das gesamte Styling von Ihren eigenen benannten Klassen vorgenommen wird, sind die Styling-Informationen nun verstreut. Einige Styling-Informationen werden direkt im HTML über die Utility-Klassen angewendet, und einige Styles werden durch Ihre eigenen Namenskonventionen und CSS angewendet.
Die andere Option ist, *vollständig* auf eine Utility-Bibliothek zu setzen. Auf diese Weise haben Sie alle Styling-Informationen vom CSS ins HTML verlagert. Es ist kein verstreutes System mehr.
Ich kann Ihnen nicht sagen, ob Sie es lieben werden, mit einem All-in-Utility-Bibliotheksansatz wie diesem zu arbeiten oder nicht, aber langfristig stelle ich mir vor, dass Sie glücklicher sein werden, wenn Sie sich entweder für den All-in-Ansatz oder für gar keinen entscheiden als für einen Zwischendurch-Ansatz.
Dies ist eine der Definitionen von Atomic CSS
Darüber können Sie hier lesen. Man könnte die Verwendung einer Utility-Bibliothek für das gesamte Styling als eine Form von „statischer“ atomarer CSS bezeichnen. Das unterscheidet sich von einer „programmatischen“ Version, bei der Sie Markup wie dieses verarbeiten würden
<div class="Bd Bgc(#0280ae):h C(#0280ae) C(#fff):h P(20px)">
Lorem ipsum
</div>
Und heraus käme CSS, das dem entspricht.
Utility-Bibliotheken
Ich werde einfach eine Reihe davon auflisten, auf die ich gestoßen bin, einige Zitate herauspicken, was sie über sich selbst sagen, und ein Codebeispiel.
Shed.css

Shed.css entstand, nachdem ich es leid war, CSS zu schreiben. Die gesamte CSS der Welt wurde bereits geschrieben, und es besteht keine Notwendigkeit, sie in jedem unserer Projekte neu zu schreiben.
Ziel: Ablenkungen für Entwickler und Designer zu eliminieren, indem eine Reihe von Optionen geschaffen wird, anstatt die „Bikeshedding“-Diskussion zu fördern, woher shed seinen Namen hat.
<button
class="
d:i-b
f-w:700
p-x:3
p-y:.7
b-r:.4
f:2
c:white
bg:blue
t-t:u
hover/bg:blue.9
"
>
Log In
</button>
Tachyons

Erstellen Sie schnell ladende, gut lesbare und 100 % reaktionsschnelle Schnittstellen mit so wenig CSS wie möglich.
<div class="mw9 center pa4 pt5-ns ph7-l">
<time class="f6 mb2 dib ttu tracked"><small>27 July, 2015</small></time>
<h3 class="f2 f1-m f-headline-l measure-narrow lh-title mv0">
<span class="bg-black-90 lh-copy white pa1 tracked-tight">
Too many tools and frameworks
</span>
</h3>
<h4 class="f3 fw1 georgia i">The definitive guide to the JavaScript tooling landscape in 2015.</h4>
</div>
Basscss

Durch die Verwendung klarer, humanisierter Namenskonventionen ist Basscss schnell zu verinnerlichen und einfach zu verstehen, während gleichzeitig die Entwicklungszeit mit skalierbarerem, besser lesbarem Code verkürzt wird.
<div class="flex flex-wrap items-center mt4">
<h1 class="m0">Basscss <span class="h5">v8.0.2</span></h1>
<p class="h3 mt1 mb1">Low-Level CSS Toolkit <span class="h6 bold caps">2.13 KB</span></p>
<div class="flex flex-wrap items-center mb2">
</div>
</div>
Beard

Ein CSS-Framework für Leute, die Besseres zu tun haben
Beards beliebteste und polarisierendste Funktion sind seine Hilfsklassen. Viele Leute sind der Meinung, dass Utility-Klassen wie die, die Beard für Sie generiert, zu Bloat führen und genauso schlecht sind wie die Verwendung von Inline-Styles. Wir haben festgestellt, dass eine reichhaltige Sammlung von Hilfsklassen Ihre Projekte einfacher zu erstellen, besser zu verstehen und kugelsicherer macht.
<div class="main-content md-ph6 pv3 md-pv6">
<h2 class="tcg50 ft10 fw3 mb2 md-mb3">Tools</h2>
<p class="tcg50 ft5 fw3 mb4 lh2">Beard isn't packed full of every feature you might need, but it does come with a small set of mixins to make life easier.</p>
<h3 class="tcg50 ft8 fw3 mb2 md-mb3">appearance()</h3>
</div>
turretcss

Turretcss wurde für das Design entwickelt und ist ein Framework zur Normalisierung von Stilen und Browserverhalten für die schnelle Entwicklung von reaktionsschnellen und zugänglichen Websites.
<section class="background-primary padding-vertical-xl">
<div class="container">
<h1 class="display-title color-white">Elements</h1>
<p class="lead color-white max-width-s">A guide to the use of HTML elements and turretcss's default styling definitions including buttons, figure, media, nav, and tables.</p>
</div>
</section>
Expressive CSS

- Klassen sind für visuelles Styling. Tags sind für Semantik.
- Beginnen Sie mit einer guten Grundlage von Basis-HTML-Elementstilen.
- Verwenden Sie Utility-Klassen für DRY-CSS.
- Klassennamen sollten auf einen Blick verständlich sein.
- Responsives Layout-Styling sollte einfach sein (sogar Spaß machen).
<section class="grid-12 pad-3-vert s-pad-0">
<div class="grid-12 pad-3-bottom">
<h3 class="h1 pad-3-vert text-light text-blue">Principles</h3>
</div>
<div class="grid-12 pad-3-bottom">
<h4 class="pad-1-bottom text-blue border-bottom marg-3-bottom">Do classes need to be ‘semantic’?</h4>
<p class="grid-12 text-center">
<span class="bgr-green text-white grid-3 s-grid-12 pad-2-vert pad-1-sides">Easy to understand</span>
<span class="grid-1 s-grid-12 pad-2-vert s-pad-1-vert pad-1-sides text-green">+</span>
<span class="bgr-green text-white grid-3 m-grid-4 s-grid-12 pad-2-vert pad-1-sides">Easy to add/remove</span>
<span class="grid-1 s-grid-12 pad-2-vert s-pad-1-vert pad-1-sides text-green">=</span>
<span class="bgr-green text-white grid-2 m-grid-3 s-grid-12 pad-2-vert pad-1-sides">Expressive</span>
</p>
</div>
</section>
Tailwind CSS

Ein Utility-First CSS-Framework für schnelle UI-Entwicklung
Dieses Ding existiert noch nicht einmal und sie haben über 700 Twitter-Follower. Eine solche Sache überzeugt mich, dass es ein echtes Verlangen nach diesen Dingen gibt, das nicht ignoriert werden sollte. Wir können uns jedoch eine Vorschau auf ihre Promo-Website ansehen
<div class="constrain-md md:constrain-lg mx-auto pt-24 pb-16 px-4">
<div class="text-center border-b mb-1 pb-20">
<div class="mb-8">
<div class="pill h-20 w-20 bg-light p-3 flex-center flex-inline shadow-2 mb-5">
</div>
</div>
</div>
</div>
Utility-Bibliotheken als Styleguides
Marvel

Während Marvel weiter wächst, sowohl als Produkt als auch als Unternehmen, ist eine Herausforderung, vor der wir stehen, zu lernen, wie wir die Markenidentität von Marvel verfeinern und sie kohärent auf jedes unserer Produkte anwenden. Wir haben diesen Styleguide erstellt, der als zentraler Ort dient, an dem wir ein Live-Inventar von UI-Komponenten, Markenrichtlinien, Marken-Assets, Code-Snippets, Entwicklerrichtlinien und mehr beherbergen.
<div class="marginTopBottom-l textAlign-center breakPointM-marginTop-m breakPointM-textAlign-left breakPointS-marginTopBottom-xl">
<h2 class="fontSize-xxxl">Aspect Ratio</h2>
</div>
Solid

Solid ist BuzzFeeds CSS-Styleguide. Beeinflusst von Frameworks wie Basscss, verwendet Solid unveränderliche, atomare CSS-Klassen, um Funktionen schnell zu prototypisieren und zu entwickeln, und bietet konsistente Styling-Optionen sowie die Flexibilität, neue Layouts und Designs zu erstellen, ohne zusätzliche CSS schreiben zu müssen.
<div class="xs-col-12 sm-col-9 lg-col-10 sm-offset-3 lg-offset-2">
<div class="xs-col-11 xs-py3 xs-px1 xs-mx-auto xs-my2 md-my4 card">
<h1 class="xs-col-11 sm-col-10 xs-mx-auto xs-border-bottom xs-pb3 xs-mb4 sm-my4">WTF is Solid?</h1>
<div class="xs-col-11 sm-col-10 xs-mx-auto">
<section class="xs-mb6">
<h2 class="bold xs-mb2">What is Solid?</h2>
</section>
<section class="xs-mb6">
<h2 class="bold xs-mb2">Installation</h2>
<p class="xs-mb2">npm install --save bf-solid</p>
</section>
<section class="xs-mb6 xs-hide sm-block">
<h2 class="bold xs-mb2">Download</h2>
<p>
<a href="#" download="" class="button button--secondary xs-mr1 xs-mb1">Source Files</a>
</p>
</section>
</div>
</div>
</div>
Dies ist getrennt, aber verwandt mit der Idee von CSS-in-JS
Die Welle in JavaScript hat sich stark in Richtung Komponenten bewegt. Die Kombination von HTML und JavaScript hat sich für viele Leute gut angefühlt, daher ist es nicht überraschend, dass sich das Styling zu diesem Trend gesellt. Und das nicht nur um des Selbstwillens willen. Es gibt verständliche Argumente dafür, darunter Dinge wie die globale Natur von CSS, die zu Konflikten und unbeabsichtigten Nebenwirkungen führt. Wenn Sie Dinge so stylen können, dass dies nie passiert (was nicht bedeutet, dass Sie auf CSS ganz verzichten müssen), gebe ich zu, dass ich den Reiz sehe.
Diese Idee, Komponenten auf JavaScript-Ebene zu stylen, scheint die Notwendigkeit von Utility-Bibliotheken weitgehend zu negieren. Wahrscheinlich eher eine oder die andere Sache.
Gute Liste von Util-Bibliotheken. Ich habe meine eigene Util/Layout-CSS-Bibliothek erstellt. Ähnliche Konzepte und konzentriert sich darauf, das Layout einfach zu gestalten. https://blueprintcss.io
Ein weiteres zu prüfendes ist iotaCSS.
Ich liebe den letzten Abschnitt deines Artikels. Ich glaube, wir nähern uns einer Konvergenz zwischen dem Atomic-CSS-Ansatz und CSS-In-JS. Diese einheitliche Styling-Sprache. Die heutige Version von CSS Zen Garden ist eine JSON-Theme-Datei, die projektübergreifend für Typografie, Farbe und Skalierung verwendet wird (BYO-Grid zum Zusammenfügen).
Strukturell sehe ich große Vorteile in der Verwendung einiger dieser Utilities, aber einige Funktionen erscheinen sehr rückschrittlich. Wenn Sie sich für fast jede einzelne CSS-Eigenschaft Klassen wünschen, dann verwenden Sie einfach Inline-Styles erneut (ein wenig Sarkasmus). Schreiben Sie also einfach gutes CSS und HTML, und die meisten dieser Bibliotheken werden nicht benötigt.
Ich stimme Bryan voll und ganz zu. Halten Sie es einfach, und so ist es beherrschbar.
Zu deinem Punkt, haben die meisten dieser Bibliotheken ein Basis-Stylesheet? Ich nehme es an, frage aber aus Unwissenheit.
Ich weiß, es war ein Witz, aber es ist erwähnenswert, dass Sie mit den Stilklassen den Vorteil haben, dass Browser die Stylesheets cachen, und Sie müssen sich keine Sorgen machen, dass Inline-Styles schwer zu überschreiben sind. Für Responsive Web Design können Sie die Klassen als mobile-first „Basis“ verwenden und sie dann mit einem Stylesheet kombinieren, um Media Queries für größere Größen zu verwenden. Es hilft, die Größe der Stylesheets (oder Sass-Partials) zu reduzieren, damit sie leichter zu lesen sind.
Diese Liste und all die Beispiele machen mich krank!
Der Zweck eines externen Stylesheets mit Klassen, die im HTML aufgerufen werden können, ist die Trennung der Belange.
Früher haben wir Stile direkt im HTML angewendet, und das war schlecht, weil die Stile mit dem HTML verknüpft waren, das Ändern eines Stils bedeutete, die HTML-Datei zu ändern, eine Gelegenheit, jederzeit etwas kaputt zu machen, und Sie mussten sich im HTML immer und immer wieder wiederholen.
Wenn Sie Klassen in Ihrem HTML einfügen, sollten Sie diese enge Kopplung vermeiden, aber wenn Ihre Klassen nur eine Sache tun (mt0, padding-left-30, ...), ist das genau so, als würden Sie Ihre Stile direkt im HTML schreiben, denn wenn Sie den Stil ändern wollen, sagen wir, eine linke Polsterung von 20 Pixeln zu haben, müssen Sie die Klasse ändern, die Sie in Ihrem HTML aufrufen, und das überall, wo Sie sie ändern müssen!
Wenn Sie eine Klasse wie 'my-title' haben, müssen Sie das HTML nicht ändern, sondern nur die Stile innerhalb der Klasse, und das nur einmal.
Gute Punkte. Ich freue mich auf die Entgegnungen dazu!
Ich würde denken, wenn Sie eine Website erstellen und bearbeiten, die nur aus reinem HTML besteht und das HTML nicht vorverarbeitet oder Module zur Ausgabe von HTML verwendet, dann sehe ich, dass Utilities ein Albtraum sein können, da Sie die Klassen für jedes Element immer wieder hinzufügen oder entfernen müssten, zum Beispiel eine lange Liste, die diese Formatierung benötigt.
Wenn Sie jedoch einen HTML-Präprozessor oder ein modulares System verwenden, das HTML ausgibt, sagen wir Pug oder Haml, und Sie Elemente haben, die geschleift oder wiederholt werden, dann bearbeiten Sie nur eine Codezeile, was Utility-Klassen sehr wartbar und für den Entwickler sehr nützlich macht.
Ich würde sagen, alles in allem ist es projektabhängig, wie die meisten Techniken da draußen :)
Nach meiner Erfahrung hat Chris absolut Recht. Ich würde dies niemandem empfehlen, der keinen Zugriff auf eine Templating-Bibliothek hat. Diese Art von Techniken verlagert die Komplexität und Logik in die Templating-Schicht.
Das gesagt, ich habe in vielen Jahren an keinem Projekt gearbeitet, bei dem ich keinen Templating-Zugang hatte, daher war dies der richtige Weg für mich.
Ich benutze diese Methode seit etwa 3 Jahren und sie macht das Leben so viel einfacher. HTML-Markup ist weniger vage, ich weiß genau, wie mein Markup angezeigt wird. Mit einer festgelegten Anzahl von Regeln (.p1, .p2, .p3, .p4 – Padding) erhalten Sie Konsistenz im gesamten Design. Es ist viel einfacher, spontan zu stylen, reaktionsschnelles Styling ist auch viel einfacher. Kleine Tests sind ebenfalls schnell zu erstellen.
Ich stimme anderen zu, diese Bibliotheken funktionieren am besten, wenn sie mit einer Templating-Engine verwendet werden. Die Möglichkeit, eine Komponente nach ihrem Dateinamen zu benennen, bringt ein wenig Spezifität zurück, die bei dieser Methode etwas verloren gehen kann.
Wenn Sie mit einem Team arbeiten, empfehle ich Basscss, da die Klassen sehr gut lesbar und schnell zu erlernen sind.
Ich finde, je größer ein Projekt wird, desto weniger muss ich die CSS-Datei öffnen, was ein sehr gutes Zeichen ist. Ich mache mir keine Sorgen, Legacy-Code zu entfernen, da es sich nur um einzelne Klassen-Utilities handelt.
Mein Hauptkritikpunkt ist jedoch, dass Ihr HTML-Markup dadurch etwas unschön aussieht.
Nie einen alberneren Ansatz gesehen… LOL…
Warum ist es „albern“?
Ich habe auch meine eigene Utility-Bibliothek mit SCSS-Mixins geschrieben. Im Grunde muss jede Utility-Klasse reaktionsfähige Varianten haben (z. B. px-10 für Padding auf der x-Achse 10 Pixel) wird zu px-10, px-s-10, px-m-10, px-l-10 und so weiter, je nachdem, wie viele Breakpoints Sie haben. Das endet mit Tonnen von CSS (von dem die meiste nie verwendet wird) und ziemlich hässlichem Markup.
Ich denke immer an reaktionsfähige Änderungen, wenn ich an diese Utility-Bibliotheken denke.
Ich habe meine Hilfsklassen, aber ich vermeide es, sie so viel wie möglich zu verwenden. Meistens prototipe ich damit und wechsle dann später zu einer richtigen Klasse.
Wie Sie sagten, am Ende bleiben diese Bibliotheken mit Tonnen von ungenutztem CSS. Danke für das Teilen Ihrer Praxis und Gedanken.
@Vicente wir haben reaktionsfähige Klassen in shed.css
und so weiter.
Ich kann den Widerstand gegen den Atomic-CSS-Ansatz voll und ganz verstehen, da er gegen viele Dinge verstößt, die viele Leute als Best Practices betrachten. Wenn wir uns jedoch auf den Aufbau modularer Systeme zubewegen, macht der Utility-Klassen-Ansatz immer mehr Sinn. Ich denke, Adam Wathan drückt es in diesem Beitrag am besten aus: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
Ja, dieser Artikel von Adam Wathan ist der einzige, der mich dazu gebracht hat, ernsthaft über Utility-Klassen-basiertes CSS nachzudenken.
Er räumt die Probleme mit HTML ein, das mit schrecklichen Klassen wie in den obigen Beispielen gefüllt ist, und schlägt Wege vor, wie dies gemildert werden kann, was Ihnen die Vorteile von semantischen Klassen UND konsistenten Utility-Klassen bietet.
Grundsätzlich schlägt er vor, die Utility-Klassen als Bausteine für die größeren semantischen Modulklassen zu verwenden. Der einfachste Weg, dies zu tun, ist jedoch mit LESS, und da wir heutzutage alle SASS verwenden, erfordert dies das Schreiben eines Mixins für jede Utility-Klasse (LESS ermöglicht es Ihnen, jede Klasse einzubinden, als wäre sie ein Mixin).
Wäre es nicht auch sinnvoller, wenn Adam einen modularen, komponentenbasierter Entwicklungszyklus aufbaut? Wo Sie ein paar Klassen in einem oder zwei Modulen ändern würden, anstatt auf einer ganzen Seite?
+1 für Adams Wathams Artikel/Video. Wenn ich in eine große Codebasis gerate, kann ich sehen, wie Utility-Klassen großartig sind. Das gesagt, ein Klassenname wie…
etwas:irgendetwasist ziemlich eklig!Persönlich stimme ich jeder Aussage von Adam Wathan in seinem Artikel voll und ganz zu. Er erklärte geschickt seinen Übergang von der Verwendung von „inhaltspezifischen“ CSS-Klassen-Namenskonventionen zu einer Kombination aus „semantischem und funktionalem CSS“, d.h. starten Sie Ihr Projekt mit funktionalen (Utility-)Klassen und bauen Sie bei Bedarf wiederverwendbare semantische Komponenten auf diesen Klassen auf. Mattan Ingram gab einige tiefe Einblicke in dieses Thema in seinem obigen Kommentar.
Sein Artikel beschrieb einen Prozess, den jeder erfahrene Front-End-Webentwickler durchlaufen hätte. Unsere Entwicklergemeinschaft hat in den letzten zehn Jahren viele Veränderungen in der Front-End-Webentwicklung angenommen. Ich denke, dass Widerstände diese Methodologien zumindest einmal ausprobieren sollten.
Ich freue mich auf sein Utility-First-CSS-Framework https://tailwindcss.com/ und auf eine stärkere Akzeptanz dieses „semantischen und funktionalen CSS“-Ansatzes.
@Greg ist es „eklig“? Oder einfach nur ungewöhnlich?
Ich finde es ungewöhnlich, genauso wie das Schreiben von JSX ungewöhnlich ist, und genauso wie das Schreiben von
.bem__classes--for-components.Entschuldigung, aber das wird sehr meinungsstark sein… IGITT!
Meiner Meinung nach macht es das HTML unlesbar und schwer zu warten für große Anwendungen und große Entwicklerteams.
@basher, ich stimme zu… bis zu einem gewissen Punkt.
Wenn es sich um eine JS-intensive Frontend-Anwendung handelt, sehe ich lieber sehr kleine Stylesheets und eine ordnungsgemäße Verwendung von Utilities. Mein „aktuelles“ Denken dazu ist, dass es einen gesunden Menschenverstand-Ansatz gibt, bei dem Sie Farben, Schriftarten usw. an einer Stelle definieren, eine Utility-Klasse für übliche Dinge wie Margins (als einfaches Beispiel) einfügen. Dann ein BEM-Stylesheet nach Bedarf für einzigartige Situationen.
Auf diese Weise müssen Sie nicht durch hundert CSS-Dateien jagen, nur indem Sie sich das HTML ansehen, oder einen Stil erstellen, der nicht extrem eingeschränkt ist, um die Verwendung eines Buttons in einer bestimmten Situation zu ändern. Ich kaufe mehr und mehr atomare/Utility-Klassen und warte gespannt auf Adams (@adamwathan) kommende CSS-Utility-Bibliothek!
Ich denke, deshalb wird Vue.js so populär. Es behält alles in einer Datei, einschließlich CSS, was es Ihnen ermöglicht, modular zu arbeiten und reguläres CSS zu schreiben.
Ich beschäftige mich seit ein paar Wochen mit Utility-basierten Bibliotheken und fände sie auf einem einzelnen Projekt nützlich, über das wir die volle Kontrolle hätten. Aber die Projekte, die unseren Benutzern die Möglichkeit geben, eigene Inhalte über ein CMS hinzuzufügen, lassen mich glauben, dass wir für diese besondere Situation die Kontrolle über Utilities verlieren.
Allerdings könnte man wahrscheinlich damit durchkommen, Standardklassen für jede oder
jeden Tag, der von etwas wie dem TinyMCE-Editor ausgegeben wird, das könnte funktionieren.
Ich möchte dies wirklich in meinem nächsten Projekt ausprobieren, die Frage ist, wie wähle ich bei so vielen? haha
Danke für das Teilen von shed.css in der Liste! Es hat uns auf TED.com gut funktioniert.
An diejenigen, die weniger begeistert sind: Ich verstehe Ihren anfänglichen Widerstand vollkommen – ich war im selben Lager, bis ich es tatsächlich ausprobiert habe. Es wird Ihnen ermöglichen, schneller und konsistenter zu arbeiten.
Für diejenigen, die nach einer ähnlichen CSS-in-JS-Lösung suchen, schauen Sie sich https://github.com/VinSpee/react-shed an.
Ich nutze das Beste aus beiden Welten – ich habe strenge reaktionsfähige Komponenten-spezifische Stile, aber auch eine Datei mit wenigen Klassen für häufig kopierte Eigenschaftssätze. Aber anstatt die Utility-Klassen in das Markup einzufügen, verwende ich SASS @extend, um sie direkt in meinen Hauptstilen zu nutzen. So bleibt alles an einem Ort und ich kann die vollständige Geschichte sehen, woher die Stile einer Komponente stammen.
Einige erinnern mich an einfaches Inline-CSS. Was mühsam ist, wenn man jemals mehrere Elemente ändern muss. Scheint mir ein Rückschritt zu sein.
Meine absolut beliebteste Sammlung von CSS-Utilities ist SUIT CSS. Ich liebe es, dass jedes Paket sehr schlank ist, einzeln installierbar und über benutzerdefinierte Eigenschaften anpassbar ist. Ich mag auch seine wortreichen, selbsterklärenden Klassennamen.
Ich mag SUIT CSS wirklich – es hat mich tatsächlich in diese Richtung gebracht. Ich habe SUIT-Klassen für alles verwendet, was ich konnte, und war enttäuscht, wenn ich davon abweichen musste. Ich habe viele SUIT-Komponenten geschrieben, die ich in meinen Projekten veröffentlicht und wiederverwendet habe. Schließlich habe ich fast alles mit Utility-Klassen gemacht und mich entschieden, den vollen Utility-Klassen-Weg zu gehen.
Dann fand ich das wiederholte Schreiben langer Utility-Klassennamen mühsam, aber ich fand
tachyonsetwas zu kurz und schwer zu analysieren.Während eines unserer Front-End-Treffen bei TED haben wir uns entschieden, eine Syntax zu entwickeln, die unseren Bedürfnissen entsprach – zuverlässig, vorhersehbar und kurz.
Shed.css ist das Ergebnis. Wir versuchen, CSS-Eigenschaften so weit wie möglich zu verkürzen. Wenn es einen Konflikt gibt, erhalten die „häufiger verwendeten (dies ist völlig anekdotisch)“ Eigenschaften den kürzeren Alias. Das bedeutet
Wir haben festgestellt, dass die Produktivitätssteigerungen den Verlust der Einarbeitungszeit, während man sich daran gewöhnt, überwiegen
Wenn ich wählen darf, ist es niemals, niemals, niemals!
Viele dieser atomaren CSS-Utility-Bibliotheken sind so aufgeteilt, dass die Klassennamen zu einer neuen Kurzschreibweise für CSS werden, sodass man CSS quasi neu lernen muss, indem man alle Kurzschriften für die verschiedenen Eigenschaft-Wert-Paare lernt. Und lange, kaum entzifferbare Listen von Klassennamen sind weder ästhetisch ansprechend noch sehr entwicklerfreundlich – es sei denn, Sie sind selbst der Entwickler der Utility-Bibliothek. Fügen Sie responsives Design hinzu, und Sie verdreifachen mindestens die Anzahl der Klassen.
Der zuvor erwähnte Artikel hat jedoch eine faszinierende Idee: Utility-First CSS, bei dem Sie mit Utility-Klassen beginnen und bei Bedarf OOCSS-Abstraktionen erstellen.
Einige CSS-in-JS-Lösungen wie Styletron verwenden intern atomare Klassennamen, aber diese sind ordentlich abstrahiert, sodass der Entwickler nicht mit Klassennamen arbeiten muss.
Chris, ich habe fast jede von Ihnen hier erwähnte Bibliothek erkundet. Eines meiner Favoriten war wahrscheinlich Tachyons (hauptsächlich wegen der Community und der frühen Adaption), aber ich wollte fragen: Haben Sie Elm erkundet? Hier ist eine großartige Ressource, wenn Sie nicht viel darüber gelesen haben. Danke!
Wenn Sie eine CSS-Utility-Bibliothek verwenden oder darüber nachdenken, auf welche Art von Projekten arbeiten Sie? Wie einige erwähnt haben, scheint dies bei einem modularen, komponentenbasierter Entwicklungsansatz weitaus nutzbarer zu sein.
Wie würden Sie dies in miesen E-Commerce-Plattformen (Hybris, Demandware usw.) für größere Entwicklerteams funktionieren sehen?
Mein Ansatz im Moment ist es, einzelne Elemente und Komponenten mit BEM zu stylen (selbst wenn ich CSS-in-JS schreibe, verwende ich immer noch BEMs Namenskonventionen).
Wenn es sich um CSS-in-JS handelt, lege ich alle Stile in die .js-Datei der Komponenten, und wenn keine .js-Zauberei involviert ist, erstelle ich einfach eine einzelne „CSS-ähnliche“ Datei, die einer Komponente entspricht, z.B. „user-card.sss“.
So if I need to change anything inside a component, there's always a single place I need to go.
On the other hand, I define utility classes as needed for the layout and spacing between elements.
Vor 2 Jahren erkannte ich bereits den Bedarf an einer funktionalen/Utility-Bibliothek und begann, meine eigene zu entwickeln, die sich Projekt für Projekt langsam weiterentwickelte.
Einige der hier vorgestellten Beispiele sind extrem, zum Beispiel:
<h2 class="tcg50 ft10 fw3 mb2 md-mb3">Tools</h2>. Klassen müssen nicht kryptisch sein. Das Schreiben von margin-bottom-xl anstelle von mb-xl macht in Bezug auf die Größe keinen so großen Unterschied, aber es macht einen großen Unterschied in Bezug auf die Lesbarkeit. Ich plane, meine Utility bald als Open Source zu veröffentlichen.Generell brauchen wir auf jeden Fall Utility-Klassen. Der Schlüssel zu weniger CSS-Problemen ist, weniger CSS zu schreiben / mehr CSS zu abstrahieren.
Nach meiner bescheidenen Erfahrung bringen Utility-Klassen immer mehr Probleme mit sich als erwartet.
Bei einer responsiven Website werden Utility-Klassen tendenziell öfter überschrieben, als sie sollten. Dies wirft viele Fragen bezüglich des Workflows auf, und ich stimme zu, dass es genug Substanz gibt, um dies zu diskutieren, aber in der realen Welt bieten diese Utility-Klassen oft mehr Einschränkungen als alles andere. Und wie viele hier möchte ich mein CSS lieber gut organisieren, als mein HTML mit nicht-semantischen Klassen zu bombardieren, was die Wartung aus meiner Sicht erschwert.
Adams Artikel ist interessant, aber ich finde seine Darstellung des von ihm vollzogenen Wandels etwas leichtfertig. Es ist nichts Falsches an einer "inhaltsagnostischen Komponente", und das ist meiner Meinung nach sehr subjektiv von ihm. Und ist das nicht übrigens das, was er tut, indem er eine vollständige CSS-Bibliothek mit Utility-Klassen aufbaut? Z.B.:
.mar-r-sm {margin-right: 1rem;}. Ich bin überhaupt nicht von seinen Argumenten überzeugt, auch wenn sie geschickt geschrieben sind und einige Punkte leicht zu Diskussionen anregen.Vielleicht hat das schon jemand erwähnt, aber die Praxis, Utility-Klassen zu verwenden, ist auf lange Sicht nicht sehr skalierbar oder wartbar. Mit anderen Worten, ich wäre entsetzt, zwanzig CSS-Klassen für ein einziges HTML-Element zu sehen.
Die Strategie, die für mich am besten funktioniert, ist,
1) Einen Präprozessor verwenden
2) Meine Utility-Klassen als Mixins schreiben
3) Durch die Nutzung dieser Mixins kann ich Klassen erstellen, die auf den ersten Blick Sinn ergeben. Entweder unter Verwendung von SMACSS, BEM oder einer anderen Benennungskonvention.
Hat jemand hier eine ähnliche Strategie verwendet? Würde mich freuen, es zu erfahren!
Tatsächlich, wenn Sie ein großes Team haben, ist dies eine sehr kluge Sache.
Wir haben kürzlich eine riesige Website überarbeitet. Wir wollten die Notwendigkeit von einmaligen CSS-Dateien und Inline-CSS reduzieren, daher haben wir das Basis-CSS schön und einfach – und lesbar gemacht, was es leicht zu merken macht.
Etwas wie
<h2 class="uppercase pad-top condensed">gibt Ihnen viel Flexibilität, ohne eine ganz neue Sprache lernen zu müssen. Und Sie wissen ziemlich genau, wie diese Überschrift aussehen wird.Ich musste für diese Website nur sehr wenig zusätzlichen CSS machen und die Effizienz des Teams ist viel höher, als wenn wir überall verwaiste Stile hatten.
Allerdings muss er bei der Aufnahme eines neuen Teammitglieds alle Utility-Klassennamen lernen, die vom gewählten System verwendet werden.
Sicher, es ist leicht zu verstehen, was "uppercase pad-top condensed" tun wird. Aber wie sollte man wissen, dass man es tun kann? Es ist bereits bekannt, wie das Aussehen dieser h2 innerhalb des CSS geändert wird – und wenn es richtig eingekapselt und modularisiert ist, sollten Änderungen nichts Schlimmes bewirken.
Ich bin nicht gegen Utility-Klassen, aber ich sehe ehrlich gesagt nicht, wie Utility-Klassen dieser Art etwas anderes tun können, als die Schulungs-/Einarbeitungsanforderungen für einen neuen Entwickler zu erhöhen. Sie kennen bereits normales CSS und wie man es benutzt.
Wäre die Lösung nicht, an der Modularität/Kapselung der CSS-Komponenten zu arbeiten, um "verwaiste Stile" zu verhindern, anstatt eine ganze Reihe neuer Klassen hinzuzufügen, die auswendig gelernt werden müssen?
@Pete Sie berücksichtigen nicht die andere Seite der Dinge – die Aufnahme eines neuen Entwicklers in "normalen" CSS-Situationen erfordert von ihm, Folgendes zu lernen:
Ihr gewähltes CSS-Namensschema
CSS-Dateistruktur
Regeln für die Erstellung neuer Komponenten in CSS
Ihr Templating-System
Alle Ihre CSS-Abstraktionen
Alle Ihre "Komponenten"-Abstraktionen aus Vorlagen
Meiner Erfahrung nach ist es für einen neuen Entwickler viel einfacher zu erkennen, was
c:black f:2 t-t:u p:1tun wird, als sich durch Code zu graben, um festzustellen, was.banner > .banner__title.headline--primarytun wird.Was @Vince gesagt hat.
@Pete: Ein neues Teammitglied muss entweder die Utility-Klassen lernen oder eine riesige CSS-Codebasis durchsuchen und versuchen herauszufinden, was nav-menu-wrapper im Vergleich zu nav-menu und nav-menu-container tut. Wenn Sie es ausprobieren würden, würden Sie feststellen, dass das erste viel einfacher ist.
Der Punkt ist jedoch – und ich denke, viel von der Skepsis rührt daher –, dass eine universelle Methode zur Hinzufügung eines Rands zu einem Element sicherstellt, dass, sobald das Vorhandensein dieser Utility-Klasse (oder Klassen-Mixins) den Entwicklern bekannt ist, eine ganze Menge Code-Duplizierung und Wiederholung vermieden wird, die Front-End-Entwickler dazu neigen, wenn CSS eine bestimmte Schwelle überschreitet, einfach weil es menschlich unmöglich ist, das Projekt durchzugehen und Klassen auf dem Laufenden zu analysieren / zu abstrahieren.
Ich überprüfe im Rahmen meiner Arbeit viele Code-Reviews, und die eine Sache, die ich ständig sehe, sind sich wiederholende Muster, unnötige CSS-Eigenschaften und Dinge, die abstrahiert werden könnten.
Functional CSS und Utility-Bibliotheken lösen dieses Problem endgültig.
Die Semantik von HTML, die vor 7-8 Jahren der heilige Gral von CSS war, wurde endgültig mit reichhaltigen / strukturierten Daten (JSON-LD, Microformats usw.) gelöst https://developers.google.com/search/docs/guides/intro-structured-data.
Gab es eine Diskussion über die Minifizierung dieser längeren Klassennamen? Da wir unser CSS und JS minifizieren, was wäre, wenn ein Präprozessor das HTML scannt, diese langen Reihen von Klassennamen findet, einen minifizierten Namen in einer Produktions-HTML-Datei erstellt und die erstellte minifizierte Klasse (mit Stilen) zum minifizierten CSS hinzufügt? Ich schätze, wir könnten auch ungenutzte Stile aus dem minifizierten CSS entfernen, da wir das HTML nach Klassennamen scannen.
Danke für den Artikel, Kumpel, es war eine gute Lektüre.
Einige dieser Frameworks / Bibliotheken sehen ziemlich gut aus, ich werde einige ausprobieren und sehen, wie gut sie zusammenarbeiten.
Die Nützlichkeit von Utility-Klassen wird Entwickler immer spalten, da einige den Durcheinander hassen, den es in das Markup bringt, während andere die modulare Natur der Code-Wiederverwendung mögen, die es mit sich bringt.
Layout-Informationen wie Breiten, zusammen mit Rändern / Abständen / Positionierung zu haben, ist eine großartige Sache (solange es über Breakpoints hinweg funktioniert)
Die Möglichkeit, die Breite eines Elements zusammen mit seinem grundlegenden Layout über verschiedene Größen hinweg zu definieren, ist ziemlich wichtig.
Beste Grüße
Vielen Dank, Chris, für das Teilen und besonders an alle für die Kommentare. Mein Kopf zerbricht sich den Kopf, da ich immer verschiedene Ansätze in meinen Projekten verwende und immer nach dem einen, dem einzigen, dem einzigartigen und dem endgültigen nützlichsten Ansatz für das Styling suche. Diese Lektüre führt mich zu einer verwandten Frage: Kennt jemand ein Werkzeug, das UNGENUTZTE CSS-Klassen aus einer CSS-Datei oder Dateien entfernt? Ich meine, gegeben eine Gruppe von HTML-Dateien, überprüft es die CSS-Dateien und entfernt die Klassen, die Sie in keiner von ihnen verwenden?
Ja, warten wir einfach ein bisschen, bis Webkomponenten weit verbreitet sind (oder verwenden Sie sie jetzt mit ein paar Eigenheiten), schreiben Sie normales CSS und beenden Sie diesen Unsinn. Oder verwenden Sie BEM mit Stylus/SASS in der Zwischenzeit.
Ein Teil dieses Unsinn kommt von Leuten, die nicht verstehen, wie man eine richtige Benennungskonvention / Struktur für CSS verwendet. Und das kann teilweise an ihrem Backend-Hintergrund liegen oder daran, dass sie "Best Practices" blind übernehmen, ohne sie in einem großen Projekt zu testen.
Meiner Erfahrung nach ist BEM für die meisten Zwecke geeignet. Ich meine, wirklich, CSS-Größe/Überschreibungen/etc. sind keine Sorge, wenn Sie Ihr Projekt richtig planen und zuerst alle Komponenten entwickeln. Die meisten Teams beginnen mit der Seitenentwicklung, ohne alle Design-Dateien zu analysieren, die Struktur zu planen und zuerst Komponenten zu entwickeln.
Jede Komponente sollte ihre eigene Datei haben und unabhängig von der Struktur sein. Das ist der schwierige Teil, bei dem die meisten Coder scheitern.
In den ersten Wochen wird es wenig sichtbare Fortschritte geben. Danach nimmt die Entwicklung einfach Fahrt auf. Diese ersten Wochen sind für den PM und den Kunden, der "etwas" sehen möchte, sehr stressig.
Diese Art von Klassen
c:black f:2 t-t:u p:1nur um der Abstraktion willenist einfach wahnsinnig. Ich muss eine weitere "Sprache" innerhalb von CSS lernen, nur um zu verstehen, was sie bedeuten. Warum sollte man das tun? Nehmen Sie dieses Projekt in ein anderes Team, und sie müssen das alles noch einmal lernen. Das ergibt einfach keinen Sinn.
Schreiben Sie gutes CSS/HTML und bauen Sie eine vernünftige Struktur.
@Zeno: Ich bezweifle, dass Sie mit echten großen Projekten mit echten Product Ownern und Designern zu tun hatten, dann wüssten Sie, dass es unrealistisch ist, vollständig vorgefertigte Designs zu erwarten, bei denen Sie die Analyse durchführen können, die Sie erwähnen. Traurig, aber wahr. Mit funktionalem CSS können Sie wirklich agil und flexibel und effizient sein.
@George meinen Sie damit wirklich agil und flexibel, wie Sie es mit reinem CSS sind, wenn Sie es richtig machen?
Die traurige Wahrheit ist, dass sich die Leute über CSS-Mängel beschweren und versuchen, es so zu machen, wie sie es sich vorgestellt haben, anstatt seine Stärken zu nutzen. Wenn Sie die Kaskade und Spezifität vermeiden, haben Sie fast die meisten Vorteile von CSS zerstört. Ich weiß nicht, wie Sie Ihre Projekte strukturieren, aber ich möchte, dass meine Komponenten die Kaskade nutzen und vielleicht je nach ihrer Position im DOM unterschiedlich aussehen.
@Zeno, ich kann Ihre Gefühle gegenüber dem Ansatz verstehen, aber bitte wissen Sie, dass der Grund dafür nicht lautet: "Ich hasse CSS, ich verstehe es nicht und ich werde eine Abkürzung nehmen".
Nehmen Sie Tachyons zum Beispiel. Adam Morse, der Mann dahinter, ist ein Designer. Er ist extrem gut mit CSS. Er hat viel nachgedacht, recherchiert. Über CSS-Architektur, über Design-Systeme.
Er ist das Gegenteil von dem, was Sie sich vorstellen, jemand, der CSS so weit wie möglich vermeiden möchte.
Hier ist ein fantastischer Artikel, den Adam über CSS-Skalierbarkeit geschrieben hat. Das ist eigentlich der Artikel, der es mir bewusst gemacht hat und mich darauf vorbereitet hat, die Methodik auszuprobieren.
Es ist lesenswert, auch wenn Sie niemals vorhaben, Utility-Klassen zu verwenden!
http://mrmrs.github.io/writing/2016/03/24/scalable-css/
Es ist nicht "nur um der Abstraktion willen, und es so zu behandeln, ist eine unfaire Charakterisierung. Der Effekt *entfernt* tatsächlich die Abstraktion aus der CSS-Schicht. Er befasst sich mit konkreten repräsentativen Eigenschaften und nicht mit geschäftlichen oder domänenspezifischen Ideen.
Anstatt sich mit Abstraktionen in Ihrem CSS und Markup zu befassen, befassen Sie sich nun nur noch mit Ihrem Markup. Ihr CSS wird zu einer Reihe von Beschränkungen und nicht zu einer zusätzlichen Indirektionsschicht.
Was die Benennung angeht, so ähneln die Abkürzungen eng den CSS-Eigenschaften. Wir haben uns für Abkürzungen anstelle von Langformen entschieden, weil die langfristigen Gewinne an Produktivität und Geschwindigkeit den kurzfristigen Lernaufwand übertrafen.
Ich habe auf eine ähnliche Sorge in einem anderen Thread geantwortet, aber es lohnt sich zu wiederholen
Die Aufnahme eines neuen Entwicklers in "normale" CSS-Situationen erfordert von ihm, Folgendes zu lernen:
Ihr gewähltes CSS-Namensschema
CSS-Dateistruktur
Regeln für die Erstellung neuer Komponenten in CSS
Ihr Templating-System
Alle Ihre CSS-"Layout"-Abstraktionen
Alle Ihre "Komponenten"-Abstraktionen aus Vorlagen
Meiner Erfahrung nach ist es für einen neuen Entwickler viel einfacher zu erkennen, was c:black f:2 t-t:u p:1 tun wird, als sich durch Code zu graben, um festzustellen, was .headline–primary tun wird.
Wirklich? Ich könnte das Element mit der Klasse headline-primary einfach inspizieren und sehen, welche Werte es hat. Wie würden Sie Elemente mit Ihren Kurzklassen inspizieren? Sie werden nie wissen, was beabsichtigt war, es gibt keine Vererbung, alles kommt direkt von diesen "funktionalen" (ich würde es eher als Inline-CSS bezeichnen) Klassen.
Warum also nicht einfach wieder Inline-Styles schreiben? Ich würde niemals eine solche Utility-Bibliothek verwenden.
Obwohl sie Inline-Styles ähneln, unterscheiden sich Utility-Klassen sehr stark in ihrer Implementierung.
Nachteile von Inline-Styles beinhalten:
Unterstützen keine Hover-Zustände, Media-Queries, Pseudo-Elemente
Sind extrem spezifisch, d.h. man kann sie nicht überschreiben
Dies ist bei Utility-Klassen nicht der Fall. Hier ist eine großartige Diskussion über den Unterschied in einem Tachyons-GitHub-Issue: https://github.com/tachyons-css/tachyons/issues/12#issuecomment-59828967
Sehr schöne Zusammenfassung, Chris!
Wenn jemand an einer realen Erfahrung (meiner eigenen) mit Refactoring und Wartung einer Codebasis mit Tachyons interessiert ist, habe ich hier einen ausführlichen Beitrag dazu geschrieben: https://hackernoon.com/full-re-write-with-tachyons-and-functional-css-a-case-study-part-1-635ccb5fb00b
Sie werden feststellen, dass mein anfängliches Gefühl für das Konzept – wie die meisten von uns – Widerwillen war. Ich finde es sehr interessant, dass die meisten Kommentare zu diesem Beitrag genau mit dem übereinstimmen, was wir alle denken, bevor wir Utility-Klassen tatsächlich in einem Projekt ausprobieren und die Vorteile sehen.
Für das Protokoll: Ich habe vor einem Monat ein neues Unternehmen beigetreten. In den letzten 4 Wochen habe ich mich mit der CSS-Codebasis vertraut gemacht, und ich bin noch lange nicht zuversichtlich, dass ich weiß, wie ich sie verwenden / erweitern kann.
Das CSS ist von sehr klugen Entwicklern sehr gut organisiert. Darum geht es nicht. Es geht um die immense kognitive Belastung, die mit dem Erlernen eines neuen Vokabulars, eines neuen Systems einhergeht. Es ist überwältigend.
Ich ertappe mich dabei, mein neues CSS auf eine bestimmte Klasse zu beschränken, damit ich andere Seiten nicht "zerbreche", während ich das System lerne. Ich erstelle sofort technische Schulden, bei meiner ersten Aufgabe. :/
Mit etwas wie Tachyons bin ich fest davon überzeugt, dass ich jeden innerhalb von 3-4 Tagen einarbeiten kann.
Ich habe kürzlich einen Live-Stream-Diskussion über Tachyons gehalten, falls Sie interessiert sind. Hier ist der Link https://youtu.be/6sOoCWowwHo, und hier ist ein Dokument, das die Diskussion zusammenfasst, für diejenigen, die einen schnellen Überblick wünschen: https://hackmd.io/s/Byc3176wW
Es ist großartig zu sehen, wie dieser Ansatz für das Frontend-Styling in den letzten Monaten an Fahrt gewinnt. Als Entwickler habe ich mit semantischen Klassennamen in CSS begonnen. Nachdem ich den Paradigmenwechsel zu Functional CSS und Utility-Klassen vollzogen hatte, habe ich nie wieder zurückgeschaut. Es beschleunigt die Entwicklungszeit um ein Vielfaches.
Tatsächlich habe ich mein eigenes hochgradig konfigurierbares Sass-Framework zur Generierung von funktionalen CSS-Klassen geschrieben
https://github.com/watchtowerdigital/scarab-carapace
Dies wurde nach der Erkenntnis entwickelt, dass ich für jedes Projekt immer wieder die gleichen Utility-Klassen schrieb. Jetzt schreibe ich kaum noch CSS. Konfiguriere einfach meine Breakpoints, Typografie, Größen, Farben usw. in scarab-carapace, und es erstellt programmatisch ein funktionales CSS-Stylesheet.
Außerdem wird scarab-carapace mit einem anderen Werkzeug, scarab-styleguide (https://github.com/watchtowerdigital/scarab-styleguide), integriert, um automatisch einen Frontend-Styleguide (Beispiel: http://scarab-styleguide.surge.sh) basierend auf der Stylesheet-Konfiguration zu generieren.