Da Atomic CSS (auch bekannt als Functional CSS) immer beliebter wird, sind einige Verwirrung über ähnliche verwandte Begriffe entstanden. Ziel dieses Artikels ist es, diese Terminologie zu klären.
Es gibt andere Projekte, die den Begriff Atomic verwenden, einschließlich Atomic Web Design von Brad Frost. Atomic CSS ist ein vollkommen eigenständiges Konzept.
Beginnen wir mit der Definition von Atomic CSS
Atomic CSS ist der Ansatz zur CSS-Architektur, der kleine, einzelzweckbezogene Klassen mit Namen bevorzugt, die auf visuellen Funktionen basieren.
Es gibt verschiedene Möglichkeiten, Atomic CSS zu schreiben (siehe Variationen unten). Ein Beispiel wäre dies
.bgr-blue {
background-color: #357edd;
}Der Begriff „Atomic CSS“ wurde von Thierry Koblenz in seinem grundlegenden Artikel „Challenging CSS Best Practices“ im Oktober 2013 geprägt.
Einige Leute begannen einige Zeit später, diesen Ansatz als „Functional CSS“ zu bezeichnen. Obwohl es in der Vergangenheit Fälle gab, in denen Functional CSS verwendet wurde, um etwas anderes zu beschreiben, werden heute die Begriffe Functional CSS und Atomic CSS austauschbar verwendet.
Während Atomic CSS der Titel eines Open-Source-Projekts war, das auf Thierry's Originalartikel basiert, bezieht sich der Begriff selbst auf die architektonische Philosophie, nicht auf eine einzelne Variation (siehe unten).
Variationen von Atomic CSS
Statisch
Viele Leute schreiben Atomic CSS so, wie sie CSS schon immer geschrieben haben. Es ist üblich, einen Präprozessor zu verwenden, um eine Bibliothek von Klassen mit festgelegten Variationen zu generieren, die ein einheitliches Designsystem für Abstände, Farben, Typografie usw. definieren.
Der Vorteil dieses Stils ist, dass er, da er vertraut ist, eine geringere Eintrittsbarriere hat und für diejenigen, die nicht gut mit CSS vertraut sind, leichter verständlich ist.
Programmatisch
Der programmatische Ansatz für Atomic CSS beinhaltet die Verwendung eines Build-Tools zur automatischen Generierung von Stilen basierend auf dem, was im HTML gefunden wird.
Zum Beispiel, gegeben dies
<!-- Programmatic Atomic CSS Example -->
<div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>Der folgende CSS-Code würde generiert werden
.Bgc\(#0280ae\) { background-color: #0280ae; }
.C\(#fff\) { color: #fff; }
.P\(20px\) { padding: 20px; }Diese Variante von Atomic CSS verwendet die Syntax eines Funktionsaufrufs mit Parametern. Wie das Open-Source-Projekt ACSS zeigt, das Atomizer verwendet, um Stile programmatisch zu generieren, ist es nicht mehr notwendig, überhaupt CSS zu schreiben. Stylesheets, die während des Build-Prozesses generiert werden, sind vollständig optimiert und enthalten keine ungenutzten Stile.
Langform/Kurzform
Der Langform-Stil bevorzugt besser lesbare Klassennamen (siehe Expressive CSS und Solid), während die Kurzform Kürze bevorzugt (siehe Tachyons und Basscss).
/* Shorthand Atomic CSS Examples */
.bg-blue { background-color: #357edd; }
.f1 { font-size: 3rem; }
.ma0 { margin: 0; }
/* Longhand Atomic CSS Examples */
.bgr-blue { background-color: #357edd; }
.background-blue { background-color: #357edd; }
.backgroundcolor-blue { background-color: #357edd; }
.text-h1 { font-size: 3rem; }
.text-3rem { font-size: 3rem; }
.text-huge { font-size: 3rem; }
.fontsize-1 { font-size: 3rem; }
.marg-0 { margin: 0; }
.margin-0 { margin: 0; }
/* Programmatic Shorthand */
Bgc(#357edd) { background-color: #357edd; }
/* Programmatic Longhand */
bgrBlue(#357edd) { background-color: #357edd; }
backgroundBlue(#357edd) { background-color: #357edd; }
backgroundColorBlue(#357edd) { background-color: #357edd; }Verwandte Begriffe
Utility-Klassen
Utility-Klassen (auch Helper-Klassen genannt) sind leicht verständliche Klassen mit einer einzigen Funktion, die bei gängigen Styling-Mustern helfen (z. B. .clearfix, .hidden).
Viele CSS-Architekturen basieren auf Utility-Klassen (z. B. Grids, Abstände, Typografie), aber sie umfassen nicht unbedingt vollständig das Konzept von Atomic CSS.
Unveränderliches CSS
Ein Aspekt von Atomic/Functional CSS, bei dem Utility-Klassen niemals verändert werden dürfen, was hochgradig zuverlässige Ergebnisse liefert.
Unveränderlichkeit spielt eine wesentliche Rolle bei der korrekten Ausführung der Atomic CSS-Architektur. Ohne sie riskieren Sie dies
.black {color:navy;}Atomic CSS verschiebt die Komplexität von Stylesheets in HTML. Wenn Designänderungen in einem Atomic CSS-Projekt auftreten, ist es am besten, gut strukturierte HTML-Vorlagen zu haben, damit Sie beispielsweise ein Bearbeitungswerkzeug verwenden können, um schnell Bgc(colorOne) in Bgc(colorTwo) zu ändern, wo auch immer Sie es benötigen.
Breakpoint-Präfixe
Diese Technik ist eine Möglichkeit, Utility-Klassen zu ermöglichen, Stile an verschiedenen Breakpoints zu überschreiben, um die Implementierung von Responsive Web Design einfach und effizient zu gestalten.
/* Examples of breakpoint prefixing */
.grid-12 /* Full width by default */
.m-grid-6 /* 2 column at medium screen sizes */
.l-grid-4 /* 3 column for large screen sizes */Erste Schritte
Unten finden Sie eine Liste von Orten, an denen Sie beginnen können, je nachdem, welche Variante Sie bevorzugen.
- Für Atomic Aces: Atomic CSS Quick Start oder What is Atomic CSS (Video)
- Für Bibliotheksliebhaber: Intro to Tachyons (Video)
- Für mutige Designer: Cooking with Design Systems
- Für Refactoring-Rebellen: Full re-write in 10 days with Tachyons and Functional CSS (Fallstudie)
- Für reaktive Entwickler: Tachyons and React und CXS
Zusätzlich sind hier einige grundlegende Artikel, die lesenswert sind
„In The Wild“
Atomic CSS hat an Popularität gewonnen, insbesondere bei denen, die es für schnelles Prototyping und, am anderen Ende des Spektrums, für große, laufende Frontend-Projekte nutzen.
- Yahoo!
- Solid von Buzzfeed
- Shed von TED
- Marvel App Styleguide
- Tachyons Gallery
Vielen Dank an Thierry Koblenz für sein Feedback zu diesem Artikel und seine harte Arbeit über die Jahre!
Noch keine Unterstützung für CSS Grid in Atomizer.
Danke für den schönen Artikel!
Wir sind auch recht begeistert von Atomic CSS und seit wir darauf umgestiegen sind, habe ich nie zurückgeblickt.
Hier ist unser Ansatz zu diesem Thema: Ekzo, wo sich der atomare Ansatz mit der BEM-Methodik trifft.
Es lohnt sich, Ekzo im Kontext von Kotsu zu prüfen, da dieses Starter-Kit die Grundlagen und Nutzungsansätze besser zeigt.
Ich muss anmerken, dass Atomic CSS meiner Erfahrung nach für große Projekte eine schmerzhafte Wahl sein kann, wenn die Website keine gute Vorlagensprache verwendet und nicht alles in Komponenten kapselt. Es kann sehr repetitiv wirken, mit langen, schwer verständlichen Klassenattributen, die überall verstreut sind.
Im komponentenbasierten Ansatz wird die gesamte „CSS“-Logik immer mit der Komponente mitgeführt. Wenn Sie also etwas ändern müssen, bearbeiten Sie einfach die atomaren Klassen in dieser Komponente, und die Magie geschieht.
Um nicht zu wiederholen, was andere zu diesem Thema sagen, aber wie unterscheidet sich das stark von Inline-Styling?
Die Namenskonvention beschreibt einzelne CSS-Eigenschaften, ohne Kontext zur Situation, in der sie verwendet wird. Klassennamen, die ihre Werte beschreiben, sind problematisch für die zukünftige Wartung (wie Sie im Beispiel black:navy erwähnen). Es klingt, als ob Designänderungen eine Massensuch- und Ersetzungsoperation auf der HTML-Seite anstelle der CSS-Seite erfordern, es sei denn, ich verstehe dieses Konzept falsch?
Wird dieses System auch zu übermäßiger Frontend-Belastung in interaktiven Szenarien führen, in denen Elemente animiert werden, basierend auf ihrem Status gestylt werden oder spezifisches responsives Verhalten erfordern?
Wenn ich nichts übersehe, fühlt sich das wie ein großer Schritt zurück an.
Meine Lieblingsdiskussion darüber, wie sich dies von Inline-Styles unterscheidet, findet sich in einer Diskussion über Tachyons, ein beliebtes Atomic CSS-Projekt
https://github.com/tachyons-css/tachyons/issues/12
Inline-CSS hat eine extrem hohe Spezifität, unterstützt keine @-Regeln, Pseudoselektor oder Pseudo-Elemente. Atomic ist dem Inline-Styling zwar in gewisser Weise ähnlich, aber.
Korrekt. Semantische Klassennamen werden Sie hier nicht finden (es sei denn, Sie haben einige Hilfsklassen eingerichtet).
Es mag auf den ersten Blick kontraintuitiv erscheinen; aber tatsächlich ist es das Gegenteil. Das Beispiel
black: navywar ein Beispiel dafür, was man **NICHT** tun sollte. Unveränderlichkeit ist grundlegend für ein funktionierendes Atomic-Setup. Zukünftige Wartung ist auf der CSS-Seite praktisch nicht vorhanden. Im Markup ändern Sie einfach die benötigten Klassen, um das, woran Sie arbeiten, anders aussehen zu lassen.Was die globale Ersetzung betrifft, so habe ich das überhaupt nicht erlebt – insbesondere nicht, wenn ich Atomic innerhalb von Frontend-Frameworks wie React verwende, wo ich nur das Atomic innerhalb einer einzelnen Komponente ändern muss. Wenn Sie eine hohe Wiederverwendbarkeit Ihrer BEM-ähnlichen Klassen erreichen, dann kann dies definitiv ein Bereich sein, der Sie betrifft. Aber selbst als ich BEM verwendete, erzielte ich eine sehr geringe Wiederverwendbarkeit meiner semantischen Klassennamen und fügte stattdessen zusätzliche Klassennamen hinzu, während ich aus Angst, etwas zu brechen, überall refaktorierte.
Nein, es sei denn, ich missverstehe Sie. Wie würde sich Atomic von der Verwendung jeder anderen Art von klassenbasierten Konventionen in diesen Bereichen unterscheiden?
Ailwyn, ich stimme Ihnen vollkommen zu.
Als Beispiel für einen Bereich, in dem diese Methode Probleme verursachen kann: Verwendung von CSS-Animationen, um von einem neutralen Zustand zu einem fokussierten Zustand zu wechseln. Zum Beispiel, wie würden Sie Dinge wie Hintergrundfarbänderungen, Hover-Zustandsfarben, Rand-/Outline-Änderungen handhaben? Diese einfachen taktilen Feedback-Zustände scheinen eher umständlich zu sein, sie unter Atomic CSS hinzuzufügen.
Wenn Ihre Anwendung visuelle Modifikatoren hat, um den Zustand eines Teils der Seite weiter zu fördern (als einfaches Beispiel: ein verspäteter Zug kann in Orange erscheinen), wie können Sie die große Anzahl einzelner Stile hinzufügen/entfernen, ohne die Klassen neu zu gestalten?
Wenn Designänderungen durch Klassenänderungen und nicht durch CSS-Änderungen vorgenommen werden, was hindert redundantes CSS daran, sich im Laufe der Zeit anzuhäufen?
Jeder Übergang/jede Animation ist eine eigene atomare Klasse, ebenso wie die einzelnen Eigenschaften. Das komplizierte Stück ist nicht die Lösung der oben genannten Probleme in Atomic, es ist nur die Festlegung Ihrer Namenskonvention. Zum Beispiel, sagen wir, wir wollten zwischen zwei Hintergrundfarben und zwei Textfarben beim Fokussieren wechseln. Hier ist ein Beispiel, wie Sie es in reinem Atomic CSS tun könnten (keine Werkzeuge). Mit der erfundenen Konvention unten verwende ich einen Kurzform-Eigenschaftsbezeichner, den Wert und dann einen Pseudo-Klassen-Buchstaben-Bezeichner als meine Namenskonvention.
CSS
.BgcDarkGray { background-color: #111; }
.BgcWhiteF:focus { background-color: #fff; }
.CWhite { color: #fff; }
.CBlackF:focus { color: #000; }
.TrsAll { transition: all .115ms ease-in-out; }
HTML
<button class="BgcDarkGray BgcWhiteF CWhite CBlackF TrsAll">Klick mich!</button>
Das Coole an all den Bibliotheken und Tools rund um Atomic ist, dass Sie keine eigene Namenskonvention entwickeln müssen, wenn Sie nicht wollen (das wollen Sie wahrscheinlich nicht). Das Verfassen ist ehrlich gesagt der schwierigste Teil von Atomic, daher empfehle ich definitiv, sich einige der Tools/Bibliotheken anzusehen.
Alle Pseudoklassen, Elemente, @-Regeln usw. würden auf die gleiche Weise wie im obigen Beispiel behandelt. Ich könnte ein H-Suffix für „Hover“ haben oder ein
@MqMinW60em-Suffix verwenden, um diese Regel nur anzuwenden, wenn sie sich in einem Fenster befindet, das mindestens 60em breit ist. Der resultierende CSS-Code für dunkelgrau bei einer Mindestbreite von 60em würde wie folgt aussehenCSS
@media (min-width: 60em) {
.BgcDarkGray@MqMinW60em { background-color: #111; }
}
Auch hier ist es nicht schwierig zu handhaben, es erfordert nur, dass Sie darüber nachdenken, wie Sie alles benennen möchten.
Die Klassen für jede Eigenschaft, die Sie in Ihrer App verwenden, werden existieren. Es liegt an Ihnen, diejenigen anzuwenden, die für den Zustand Ihrer App zu diesem Zeitpunkt erforderlich sind. Sagen wir, ich muss bei einem API-Anforderungsfehler eine Fehlermeldung anzeigen. Der neutrale Zustand HTML könnte etwa so aussehen (ich verwende hier Atomizer-Klassen)
HTML
<output class="D(n) Ta(C) Fz(1.25em) C(#111)"></output>
Dann tritt ein Fehler auf, die Meldung muss angezeigt werden und der Text wird rot angezeigt ... also wird der HTML-Code zu
HTML
<output class="Ta(C) Fz(1.25em) C(#f00)">Es gab ein Problem!!</output>
Ich wende nur die Klassen an, die ich benötige, um das gewünschte Aussehen zu erzielen. Ich entferne/füge einfach Klassen nach Bedarf hinzu.
Die Tatsache, dass Atomic CSS-Klassen eindeutig und unveränderlich sind. Sie ändern sich nie und werden nie neu definiert. Nur die CSS-Eigenschaften, die Sie benötigen, sollten atomare Klassen haben. Atomic ist die CSS-Konvention als Antithese zur Redundanz.
Wie ist das also besser als nur Inline-Styles zu verwenden? Viele dieser Beispiele fühlen sich für mich so an, als hätten sie viel von derselben Zerbrechlichkeit, die damit einhergeht, alle Ihre Stile auf jedem Element neu zu definieren, mit dem zusätzlichen Aufwand, Ihre Stile sowohl in Ihren Klassennamen als auch in Ihrer CSS-Datei zu haben.
Inline-Styles unterstützen keine @-Regeln, Pseudoselektor oder Pseudo-Elemente. Außerdem haben sie eine extrem hohe Spezifität (was vielleicht erwünscht ist oder auch nicht).
Denken Sie an die vielen Vorteile von Unveränderlichkeit und funktionaler Programmierung in Ihrem JavaScript. Wenden Sie dieses Denken nun auf Ihr CSS an. Das ist es, was Atomic Ihnen im Grunde gibt.
Wenn Sie ein kleines Projekt selbst betreuen, gibt es möglicherweise nicht viele Vorteile. Aber wenn Sie skalieren (sowohl in Umfang als auch in Teamgröße), beginnt Atomic wirklich zu glänzen, insbesondere mit den verfügbaren Werkzeugen. Der resultierende CSS-Code wird kleiner sein und Sie werden sich komplett vor Refactoring retten.
Ich habe kein Interesse an diesem Thema, außer an der Faszination, die Entwicklungswerkzeuge zu beobachten und sie so gut wie möglich zu verstehen.
Eine Sache, die oft schwer zu artikulieren ist, wenn es um neue Werkzeuge geht, ist, wann genau man sie einsetzen sollte. Die Antwort ist selten, wenn überhaupt, sofort und in allen Situationen.
Eine dieser Situationen ist meiner begrenzten Erfahrung nach in großen Teams mit großen Codebasen. Das Gefühl ist, dass das CSS viel zu groß werden kann und die Teammitglieder im Wesentlichen Angst davor haben, und das CSS wird scherzhaft, aber treffend, „nur zum Anhängen“.
Da kommt ein Werkzeug, das das Versprechen erfüllt, viel weniger CSS zu liefern und auf eine Weise, die (nach einer Lernkurve) niemand mehr fürchtet… Ich kann die Anziehungskraft verstehen.
Bedeutet das, dass ich es bei jedem Projekt einsetzen werde und erwarte, dass Sie das auch tun? Nein.
Offenlegung: einer der shed.css Autoren hier.
Sie haben genau das Problem getroffen, das uns dazu veranlasste, diesen Ansatz zu verfolgen, die „nur zum Anhängen“-CSS-Troppe. Selbst in einer „richtigen“ BEM-Codebasis wird es ab einer bestimmten Größe eines Projekts oder einer Website schwierig. Nach vielen Diskussionen entschieden wir uns, einen funktionalen Ansatz für TED.com zu versuchen. Nach 10 Monaten, 9 Produkteinführungen und der Einarbeitung von 3 Frontend-Entwicklern haben wir festgestellt, dass ein funktionaler Ansatz für CSS seine Versprechen erfüllt.
Ich denke, wenn Sie es eine kurze Zeit lang verwenden, werden Sie sich so sehr verlieben, dass Sie es bei jedem neuen Projekt verwenden werden, weil es wirkliche Probleme jeder Größenordnung löst.
Umformulierung von https://twitter.com/j9t/status/851462393204940804: Das Problem mit Atomic CSS ist, dass es Wartbarkeit einfach ignorieren möchte, aber es wirkt so, als würde es sie nicht verstehen.
Ich denke, es lohnt sich zu erwähnen, dass es wie jedes Werkzeug weise und nicht exzessiv eingesetzt werden sollte.
Wenn Sie beispielsweise ein Muster in der Verknüpfung kleiner Utility-Klassen bemerken – kapseln Sie es in eine verständliche Musterklasse, wie z. B. „Object“ (Beispiel).
Ihre spezifische Komponente erhält zu viel Styling und sollte schwierige Beziehungen zwischen inneren Elementen ausdrücken? Zeit, sie in eine Componentenklasse zu kapseln, sonst werden Ihre Entwickler Schwierigkeiten haben, alle Beziehungen zu verstehen und warum Sie genau bestimmte Utilities verwendet haben.
Der letzte Punkt ist in der Tat ziemlich wichtig. Das Ausdrücken von Beziehungen zwischen Elementen ist die Schwachstelle von Atomic CSS, und wer es verwendet, sollte sich dessen immer bewusst sein.
Gute Arbeit, John!
Ich bin seit meinen ersten Experimenten mit Atomizer von Atomic CSS fasziniert und nutze es derzeit in mehreren Projekten bei der Arbeit. Anfangs haben wir Atomizer verwendet, aber seitdem sind wir zu einem von mir geschriebenen Tool namens Pre-Style gewechselt (eine CSS-in-JS-Variante, die es Ihnen ermöglicht, Inline-Code zu schreiben und beim Build atomare Klassen auszugeben).
Die Unveränderlichkeit hat unsere Refactoring-Zeit drastisch reduziert und durch die Verwendung von Tools wie Atomizer/Pre-Style ist sichergestellt, dass unsere Stylesheets immer nur so groß sind, wie wir sie brauchen, und niemals größer.
Selbstverständlich wird Atomic CSS von diesem Entwickler sehr empfohlen!
Einige dieser Klassennamen machen mich traurig. „.text-3rem“ vermischt funktionale und visuelle Spezifikationen. Was ist, wenn dieses Element 3,375rem sein muss? 2,975rem? NUTZEN SIE SEMANTISCHE NAMEN. Wenn dies beispielsweise eine Unterüberschrift ist, nennen Sie sie .subhead oder .text-subhead, wenn dies für das Projekt angemessen ist.
Dasselbe gilt für Dinge wie .bgrBlue. Wenn der Hintergrund dieses Elements zu einem Grünton geändert werden muss, müssen Sie nicht nur die Farbdefinition aktualisieren, sondern auch Ihr Markup aktualisieren oder die lächerliche Situation akzeptieren, in der .bgrBlue tatsächlich grün ist.
Das ist es, worüber ich mir Sorgen mache.
Ich passe wahrscheinlich besser zu dieser Denk- und Arbeitsweise für die meisten meiner Projekte als zu atomaren Ideen, aber ich bin neugierig auf andere Ansätze und offen dafür. Geistige Enge und das Angreifen anderer Ideen mit Emotionen und Geschrei sind schlechter für das Web als jeder Klassenname.
Ich glaube nicht, dass ich hier jemanden angegriffen habe, noch glaube ich, dass ich engstirnig bin, daher bin ich mir nicht sicher, woher das kam.
Ich sehe nicht ein, warum Atomic und semantische Klassennamen zwangsläufig im Widerspruch stehen, aber wenn ich gezwungen bin, eines oder das andere zu wählen, werde ich immer semantische wählen. Vielleicht arbeite ich alleine oder manchmal mit einem anderen Entwickler, sodass ich nicht auf das Problem großer Projekte mit vielen Entwicklern stoße, aber ich bevorzuge es, Dinge nach Namespace zu segmentieren und am Ende „Duplikate“ zu haben (d. h. .component1 .subhead und .component2 .subhead vs .subhead3rem).
Es kam daher, dass ein Klassenname „traurig“ genannt wurde und Dinge IN GROSSBUCHSTABEN GESCHRIEBEN WURDEN.
Ja! Meinungen auf Ihre Erfahrung zu beschränken ist viel wertvoller. Dort bin ich. Ich arbeite alleine und in kleinen Teams. Das Web ist groß und wir alle stehen vor einzigartigen Herausforderungen.
Was sind die Vorteile der Verwendung von semantischen Klassennamen im Vergleich zu funktionalen?
Sie helfen unseren Apps nicht, schneller zu laufen oder Endnutzern in irgendeiner Weise zu nützen. Sie verbessern weder die Zugänglichkeit noch die SEO. Soweit ich weiß, sind semantische Klassennamen wirklich nur Metadaten für Entwickler, damit sie wissen, was sie in den entsprechenden CSS-Dateien ändern müssen.
Wenn das der Fall ist… was ist dann wirklich falsch daran, einen funktionaleren, unveränderlichen Ansatz für CSS zu wählen, insbesondere einen, der sich als effizienter erweist als seine semantischen Gegenstücke?
Dieses Szenario würden Sie bei der Einhaltung der Atomic-Konvention nicht antreffen. Atomare Klassen sind unveränderlich. .bgrBlue wäre blau und wäre immer blau; .bgrGreen wäre grün und wäre immer grün. Wenn Sie die Hintergrundfarbe ändern wollten, würden Sie die Klassennamen auf dem Element selbst im Markup austauschen. Dieses Prinzip der Unveränderlichkeit gibt Atomic-basierten Werkzeugen die Fähigkeit, jedes CSS zu entfernen, das nicht mehr verwendet wird, während des Build-Prozesses, was zu CSS führt, das nur die für Ihre Website benötigten atomaren Klassen enthält.
Also, ist das genau dasselbe wie Inline-Styling? Was ist, wenn Sie 12 Buttons auf einer Seite haben, die akzentuiert sein sollen? Anstatt eine Klasse
button-accentzu korrigieren, ersetzen Sie 12 Vorkommen vonbackground-bluedurchbackground-green?Ich glaube, ich verpasse etwas, denn das scheint mir nicht sehr praktisch zu sein.
Wenn Sie neugierig sind, warum einige diese Methodik wählen, empfehle ich Ihnen diese beiden Artikel
Komplette Neufassung in 10 Tagen mit Tachyons und Functional CSS: Eine Fallstudie
https://hackernoon.com/full-re-write-with-tachyons-and-functional-css-a-case-study-part-1-635ccb5fb00b
Functional CSS erstellen und ausliefern
https://medium.com/@cole_peters/building-and-shipping-functional-css-4f29b947bcb9
Oder machen Sie
.bgrBlue .bgrAddYellow, um grün zu bekommen. :P Nur ein Scherz.Ehrlich gesagt, stimme ich Ihnen vollkommen zu. Die Idee von Komponenten und der Verwendung von atomaren Teilen, um zu viele Abhängigkeiten zu vermeiden, ist sinnvoll. Die Idee, Klassen für einzelne Eigenschaften zu verwenden (es sei denn, es handelt sich um etwas wie
.hidden { display: none; }), ergibt nicht wirklich viel Sinn.Noch ist es nicht viel besser als Inline-Styling.
Ich verstehe (und nutze tatsächlich) ein paar "farbbezogene" Klassen, wenn ich an mobilen Hybrid-Apps (PhoneGap) arbeite, wenn das Framework diese bereitstellt. Aber diese gehen selten über eine einzelne
layout-red-Klasse auf dem HTML-Element hinaus oder etwas Ähnliches, und das Ändern dieser Klasse in eine andere derselben Thematik ändert alles. Das wäre eine Situation, in der es Sinn machen könnte.Hallo Rick,
Sie möchten vielleicht diesen Artikel lesen: http://cssmojo.com/opinions_of_leaders_considered_harmful/
Er diskutiert die Bedeutung von "SEMANTISCHEN NAMEN"...
Ja, ich habe dieses Atomic CSS auch für ein Kundenprojekt verwendet https://www.scislides.com. Lassen Sie mich meine Meinung dazu teilen: Es ist ein großartiges Werkzeug, aber gleichzeitig schwer zu verwalten, besonders in großen Projekten. Dieses Atomic CSS hat mir bei Dingen wie Media Queries, kontextbezogenen Styles und Pseudoklassen geholfen.
Das ist interessant, da es genau das Gegenteil von dem ist, was ich vermutet hätte. 1) Schwer zu verwalten in einem großen Projekt. 2) Nützlich für Dinge wie Media Queries, was meiner Meinung nach seltsam unintuitiv zu verwalten wäre, nur mit Klassennamen.
Wenn ich mir den CSS-Code dieser Seite ansehe (es sei denn, er wurde seit Ihrer Arbeit daran aktualisiert), glaube ich, dass Sie einen großen Teil der Implementierung von Atomic CSS missverstanden haben.
Ich habe keine Meinung dazu, welche Methode die beste ist, aber Ihre Meinung darüber, wie schwer ein Werkzeug zu verwalten ist, wäre stark gefärbt, wenn Sie es nicht korrekt implementiert hätten.
Ihr CSS ist meist modülbasiert mit einem kleinen Spritzer von Atomic.
Ich frage mich immer noch, wie man dieses Konzept in WordPress implementieren könnte. Das Aufteilen des Templates in kleinere Komponenten, die auch Unterkomponenten enthalten könnten, klingt ziemlich gut, aber ich habe dafür noch kein gutes Beispiel in WordPress gefunden.
Zuallererst vielen Dank für den Artikel.
Ich habe eine Frage, die aber unbeantwortet bleibt - tatsächlich wird sie nie angesprochen, wenn über CSS-Methoden gesprochen wird, also ist das kein großes Problem.
Wie gehen Sie mit Barrierefreiheit um? Z.B.
-ms-high-contrast,inverted-colorsoderlight-level(MQ Level 4, sollten sie irgendwann implementiert werden)Ich habe noch nie jemanden gefunden, der bereit ist, diese Frage zu beantworten, aber ich hätte wirklich gerne Feedback dazu.
Mit Atomic werden alle MQ's auf die gleiche Weise gehandhabt.
In Atomizer definieren Sie Media Queries in der Datei
atomizer.config. Sie könnten also eineinvc(oder was auch immer Sie möchten) Media Query definieren und sie dann so verwenden:class="Bgc(blue)--invc", was bedeutet, dass dieses Element die Hintergrundfarbe Blau haben soll, wenn die invertierte Media Query aktiv ist. Atomizer kümmert sich um das Schreiben des eigentlichen CSS für Sie.Mit anderen Tools können Sie es inline schreiben, wie hier (React-Beispiel)
Alle Instanzen dieser Media Query werden zusammengeführt und alle Eigenschaften innerhalb der Media Query erhalten ihre eigene atomare Klasse. Alle Pre-Style-Blöcke würden in eine externe CSS-Datei geschrieben.
TL;DR – Kurz gesagt: Atomic ist typischerweise ein Selektor pro Eigenschaft, sei es ein typischer Klassenselektor, ein Pseudo-Selektor/-Element oder innerhalb einer Media Query.
Eine Möglichkeit wäre, sie ähnlich wie die Präfixe für Breakpoints zu handhaben (z.B. eine Klasse wie .dim-text-black verwenden, um die Textfarbe für gedimmtes Licht auf Schwarz zu setzen).
Ein bisschen schamlose Eigenwerbung, aber ich möchte gerne noch ein neues hinzufügen, das ich kürzlich entwickelt habe, namens hydrogencss. Hauptsächlich für die Verwendung mit CSS Modules, aber es könnte auch mit anderen Dingen verwendet werden. https://github.com/eddiemoore/hydrogencss
Das Gute daran ist, meiner Meinung nach, dass man so wenig oder so viel davon einschließen kann, wie man möchte.
Aus irgendeinem Grund finde ich
.black{color:navy}weniger anstößig, als nicht in einem Rutsch jede Instanz dieses Schwarz ändern zu können. Probleme dieser Art können durch einfaches Umbenennen gelöst werden, um sie verständlicher zu machen. Anstatt des Selektors "black" könnte es "color-default" heißen.Ich sehe einfach keine Vorteile darin. CSS wurde genau dafür geschaffen, damit wir weitreichende Änderungen mit wenig Schreibaufwand vornehmen können.
Die Verwendung von
.color-default,.color-primary,.color-secondaryals Selektoren anstelle von.blackist eine vollkommen akzeptable Methode, um Atomic CSS anzuwenden.Ich stimme zu. Ich mag die Verwendung von Dingen wie "color-primary" und "color-secondary" oder "bg-color-primary" und "bg-color-secondary", um es flexibel und dennoch einfach mit wenigen Änderungen anzupassen.
Antwort an @Lazza (konnte nicht auf den Thread antworten)
Es wird ähnlich geschrieben, aber die inneren Abläufe bei
class="BgcBlue"im Vergleich zustyle="background-color: blue;"sind sehr unterschiedlich. Ich habe einige davon in anderen Kommentaren erläutert.Wie genau akzentuiert? Wenn Sie die
background-coloreines Buttons ändern möchten, verwenden Sie einfach eine andere Klasse. Die zugrunde liegenden CSS-Klassen ändern sich nicht, sie sind unveränderlich. Also wird aus<button class="AccentBlue">Klick mich</button>ein<button class="AccentGreen">Klick mich</button>. Wenn Sie reines HTML ohne Templating, Partials oder Server-Includes verwenden, dann ja... müssen Sie alle 12 Vorkommen manuell ersetzen. Aber seien wir ehrlich... was ist üblicher: 12 Button-Hintergrundfarben auf einmal ändern (Heiliger unentschlossener Designer, Batman) oder einen dieser Buttons von den anderen abheben zu müssen? Atomic ist bei Letzterem absolut hervorragend. So sehr, dass Sie sich nie wieder Sorgen machen müssen, dass CSS-Änderungen zu Fehlern führen. Wenn es häufiger das Erstere ist, dann ist Atomic möglicherweise keine gute Lösung für Sie oder Ihr Team.Wenn Sie einen CodePen erstellen möchten, um zu zeigen, was Sie meinen, bin ich gerne bereit, eine Atomic-Version zu erstellen, um meine Aussage hier zu veranschaulichen.
Es ist meine persönliche Ansicht, dass Atomic CSS den Endbenutzer über die Bequemlichkeit des Entwicklers stellt. Werkzeuge wie Atomizer, Pre-Style und Bibliotheken wie Tachyons und Basscss machen das Schreiben in Atomic jedoch viel besser.
Haha! :)
Warum macht das Konzept von "atomaren Teilen" oder einfach das Beibehalten von "DRY" (Don't Repeat Yourself) Sinn für Komponenten (oder HTML und JS), aber nicht für Ihr CSS? Wiederverwendbarkeit bedeutet weniger Code-Wiederholung, was kleinere Dateien bedeutet, was schnellere Ladezeiten bedeutet.
Sollten Sie ausschließlich wegen der geringen Performance-Vorteile zu Atomic wechseln? Wahrscheinlich nicht. Sie wären besser dran, ein Bild aus Ihrer Anwendung zu entfernen. Aber diese Performance-Vorteile sind das i-Tüpfelchen auf einer sehr, sehr wartungsfreundlichen Eiscremeschüssel. Der Faktor der Unveränderlichkeit bedeutet, dass ich ein Jahr später zu einem Projekt zurückkehren und weitreichende Stiländerungen an einer Gruppe von Komponenten vornehmen kann, ohne mir Sorgen machen zu müssen, etwas irgendwo zu beschädigen. Diese Sicherheit erhalten Sie nicht mit semantischen Klassenschemata, es sei denn, Sie verzichten vollständig auf jede Art von Wiederverwendbarkeit. Darüber hinaus erhalte ich alle Vorteile der Selektor-Spezifität von BEM.
Danke für deine Antwort.
Im Allgemeinen, wenn ich ändern möchte, wie Buttons auf meiner Website aussehen, möchte ich nicht *einen* Button ändern, ich möchte alle ändern, es sei denn, einer ist besonders. CSS wurde erfunden, um Wiederholungen zu vermeiden und Stil von Inhalt zu trennen.
Ich möchte keine "bunte" Klasse an Elemente binden, weil die Änderung jeder Instanz davon ein *Albtraum* sein wird. Was ist, wenn ein Unternehmen seine Primärfarbe von Blau zu Rot ändert? Werde ich alle Klassen auf jedem
.color-blue-Element ersetzen oder werde ich einfach eine einzige, semantische.color-accent-Klasse neu definieren?Um ehrlich zu sein, bevorzuge ich Letzteres. :)
Ich sehe nicht, wie diese Dinge damit zusammenhängen, welchen CSS-Ansatz Sie verwenden. Sie können ein WordPress-Template mit allen Arten von serverseitigem Zeug schreiben und richtiges semantisches CSS verwenden. Wenn Sie PHP verwenden, um
<?php print_correct_accented_color_class_name_here(); ?>anstelle vonclass="accented"zu schreiben, scheint es mir, als würden Sie versuchen, den Zweck von CSS zu umgehen, um es auf dem Server neu zu erstellen. Oder mit CSS-Präprozessoren, die nur nette (aber überflüssige) Abstraktionstools sind, die am Ende normales CSS produzieren.Antwort an @Lazza
CSS wurde *vor 20 Jahren* erfunden. Sein ursprüngliches Ziel bezieht sich auf Anliegen, die sich seitdem weiterentwickelt/verändert haben. Wie ich in diesem Artikel diskutiert habe, ist die Trennung der Anliegen für viele Entwickler inzwischen ein nicht mehr relevantes Thema.
Meiner Meinung nach kann man die Vorteile von Atomic CSS nicht verstehen, ohne zuerst zu akzeptieren, dass es "okay" ist, Stile *außerhalb* von Style-Sheets zu ändern. Und die Bemerkung von Michal scheint meinen Punkt zu beweisen
:-(
Thierry, ich verstehe, dass Sie, da Sie den Begriff Atomic CSS geprägt haben, denken, es sei die beste Idee aller Zeiten und man sollte es nicht kritisieren, aber ich würde sagen, lassen wir einen ruhigen Ton.
Vielleicht, abhängig davon, was "außerhalb" bedeutet. Sicherlich werden Sie nicht "richtiger" sein, wenn Sie etwas fett schreiben. :) Wenn mit "außerhalb" gemeint ist, eine seltsame
class='text-centered'hinzuzufügen, sollten wir dann nicht zum ganzen Thema der präsentationsorientierten HTML-Tags zurückkehren und<center>wiederbeleben... oder noch mehr hinzufügen. Hurra für<h1 color='red'>, nehme ich an?Ich behalte das CSS, aber Sie können gerne die unsemantische Markup behalten.
Evolution ist eine Sache, Regression zu dem, was wir vorher verwendet haben (wie die zuvor erwähnten "visuellen" Tags) ist eine andere Sache. Ist es nicht seltsam, dass die meisten Leute, die Atomic, BEM oder was auch immer verwenden, am Ende Präprozessoren, Compiler oder andere Spielereien verwenden müssen, um den semantischen Aspekt von CSS wiederherzustellen, der beim Verwenden eines dieser Ansätze verloren ging?
Das bedeutet nicht, dass die Verwendung von Atomic CSS illegal ist oder dass Ihnen jemand böse sein wird. Es ist nur eine sehr seltsame Art der Verwendung von CSS, die sich völlig von dem unterscheidet, wofür es entwickelt wurde. Weniger praktisch. Ähnlicher wie bei Inline-CSS, was in mehreren Fällen auch nicht sehr gut ist.
Es bedeutet auch nicht immer, dass es eine schlechte Idee ist. Ich kann mir ein paar Situationen vorstellen, in denen es eine gute Idee sein könnte. Ich kann mir auch ein paar Situationen vorstellen, in denen ich Inline-CSS verwenden würde (oder verwendet habe) (was fast dasselbe ist), aber ja... man sollte vorsichtig sein. Sparsam verwenden. ;)
Ihr Artikel trägt den klugen Titel "Opinions of Leaders Considered Harmful" und geht dann in einem sehr langen Text weiter, in dem Sie als Anführer eine schädliche Meinung abgeben. Es gibt auch ein bisschen *ad hominem* hier und da, das verwendet wird, um die Argumente praktisch aller anderen Leute anzugreifen, was meiner Meinung nach keine sehr gute Vorgehensweise ist.
Wir könnten auch darüber diskutieren, wie Sie Best Practices (die sich aus der Funktionsweise von CSS und der Vereinfachung der Stilwartung ergeben) als einfache "Meinungen" definieren, aber... vertagen wir das.
Auch das Konzept von Atomic CSS, Klassen hinzuzufügen, die sich auf die Darstellung beziehen, im Markup scheint darauf hinzudeuten, dass Sie erwarten, dass ein bestimmtes Markup zu jeder Zeit nur auf eine Weise gestylt wird (was offensichtlich nicht der Fall ist, da man ein Druck-Stylesheet oder ein mobiles Stylesheet haben kann, aber das ist ein anderes Thema).
Was Sie über Atomic CSS geschrieben haben, funktioniert auch sehr gut für "altes CSS".
Antwort an Lazza
Nein! Und wenn Sie sich die Zeit nehmen, meine Artikel dazu zu lesen, werden Sie feststellen, dass dies nicht der Fall ist. Oder Sie können einfach meine Antwort an @unleashit in einem Kommentar unten prüfen, in der ich sage: "Ich sage hier nicht, dass Atomic CSS das Beste ist, was man verwenden kann, ich gebe Ihnen nur Feedback zu Ihren Annahmen".
Es wird fett dargestellt, um Betonung anzuzeigen.
Was ist mit Ihrem "lassen wir einen ruhigen Ton." passiert?
Ein sehr kurzer Text, der die Unterschiede erklärt
https://acss.io/frequently-asked-questions.html#how-is-atomic-css-different-than-using-inline-styles-
Im Falle von ACSS würde man *nicht* das tun, was in diesem Artikel vorgeschlagen wird ("Ändern von
Bgc(colorOne)zuBgc(colorTwo)), einfach weil ACSS es Entwicklern erlaubt, "Variablen" über eine Konfigurationsdatei zu verwenden. In diesem Fall würde man eine Klasse wieBgc(color-primary)im gesamten Projekt verwenden und dann die Farbe an einer Stelle ändern – der Konfigurationsdatei.Das klingt sehr nach der Verwendung von
.background-primary {
background-color: colorOne;
}
Aber das Rad neu erfinden durch Konfigurationsdateien, Präprozessoren und so weiter.
Antwort an @Lazza
Ich glaube, Sie verpassen den Punkt. Eine Konfiguration oder ein Präprozessor ermöglicht es, Farbwerte *innerhalb von Style-Sheets* projektweit zu ersetzen, anstatt Klassen im Markup zu ändern – wie oft vorgeschlagen.
.background-primary {
background-color: colorOne;
}
.color-primary {
color: colorOne;
}
.border-primary {
border-color: colorOne;
}
Passt das zum Thema "Anwendungslogik auf Client-Seite", die von Front-End/Design-Leuten entwickelt wird, weil sie clientseitig ist?
Es gibt mir das Gefühl, dass es ein Versuch ist, CSS für Leute, die CSS nicht verstehen (wie vielleicht Programmierer/Server-Side-Entwickler, die jetzt wegen Frameworks wie Angular im Frontend arbeiten), "einfach" zu machen.
Ich bin sicher, es gibt viele Frontend-Entwickler, die sich in letzter Zeit sehr bemüht haben, besser in JavaScript etc. zu werden. Können wir nicht dasselbe für unser CSS verlangen?
Ich wünschte, wir könnten ein paar Schritte zurückgehen und Programmierung als Programmierung und UI-Entwicklung als UI-Entwicklung belassen.
Ich frage mich manchmal, wohin sich das Web mit all dem entwickelt.
CSS und (SCSS/LESS) ist einfach und leicht zu befolgen. Dies fügt nur eine weitere Ebene hinzu, die dem Nutzer – dem Designer – keinen Vorteil bringt!
Was meinst du, @Colin? Unser Designteam verwendet Functional CSS. Ich würde argumentieren, dass es für einen Designer einfacher ist, einen Klassennamen von "red" zu "dark-red" zu ändern, als sich das Markup anzusehen, zu sehen, dass es sich um ein
.Button.Button--primaryhandelt, die entsprechende Datei zu finden, nachcolor: redim.Button-Element zu suchen, wenn es dort nicht ist, in.Button--primaryzu suchen, es dort zu ändern, die gesamte Anwendung zu überprüfen, um sicherzustellen, dass sie nichts unbeabsichtigtes geändert haben (einButton--primaryan anderer Stelle).Danke John, dass du das geschrieben hast.
Nur eine Fußnote. Ich denke, Techniken wie diese rufen Leidenschaft hervor, weil sie eine Art Schlachtfeld zwischen dem alten KISS-Ansatz und der neuen Welle von Ingenieuren darstellen, die sich kürzlich für das Frontend interessiert haben und ihre (manchmal) überkonstruierten Ideen mitbringen. So dramatisch das Wort "Schlachtfeld" auch klingen mag, diese neuen Stimmen sind diejenigen, die die Branche beachtet und zum Besseren oder Schlechteren wahrscheinlich zu den erwarteten Praktiken der Gegenwart/Zukunft werden. Ich bin für Komposition und funktionales Programmieren, in der "Programmierung". Aber ich denke, es ist ein bisschen gefährlich, CSS und die Themensicht Schicht all diesen Konstrukten auszusetzen. Es tut mir leid, aber Atomic CSS ist unnötig und eine überkonstruierte Idee.
Es ist nicht so, dass ich keinen offenen Geist hätte, es ist nur so, dass ich denke, dass es falsch ist und im Grunde aus Teams resultiert, die mit CSS unzufrieden waren, weil entweder a) sie es nicht gut verstehen oder b) sie nicht die richtigen kollaborativen Systeme hatten oder sie nicht durchgesetzt haben oder c) sie sich persönlich zufrieden fühlen, indem sie kühne Schritte unternehmen, um Probleme zu lösen, auch wenn die neue Lösung ein neues Problemset schafft, das größer ist als das ursprünglich Vorhandene.
Meiner Meinung nach ist CSS alles andere als perfekt. Warum brauchen wir Sass/Postcss/Bem? Ich denke einfach, die Leute sollten ihre Zeit damit verbringen, an der Verbesserung von CSS selbst (und der Browserunterstützung) zu arbeiten, anstatt an Notlösungen wie dieser. Tut mir leid, ich möchte nicht wirklich das Markup in 500 React-Komponenten-Dateien ändern, nur weil ich eine andersfarbige Schaltfläche möchte. Für mich ist das lächerlich. Wenn Sie so viel Angst haben, Ihr CSS zu verändern, schlage ich Therapie vor :p (und bessere Schulung in CSS).
Nein, die Idee kommt *nicht* von "einer neuen Welle von Ingenieuren, die sich kürzlich für das Frontend interessiert haben"; ich gehöre nicht zur neuen Welle und habe keinen Ingenieurhintergrund. Auf der anderen Seite glaube ich, dass ich ein *gutes Verständnis* von CSS habe.
Bezüglich b) würde ich sagen, es ist das Gegenteil, Atomic CSS *erleichtert* Workflows, da es keine strengen Regeln (d.h. Namespacing) befolgen muss. Gleiches gilt für c) Atomic CSS adressiert einen *anderen* Satz von Problemen (d.h. Bloat/Performance), die für einige wichtiger sein mögen...
Ich sage hier nicht, dass Atomic CSS das Beste ist, was man verwenden kann, ich gebe Ihnen nur Feedback zu Ihren Annahmen.
Hallo Thierry, zunächst einmal ist meine Absicht nicht konfrontativ. Ich sehe, dass Sie leidenschaftlich dabei sind, und ich habe gerade Ihren Smashing-Artikel gelesen und mehr Kontext erhalten. Selbst wenn Sie keinen Ingenieurhintergrund hatten, arbeiten Sie (wie andere große Technologieunternehmen) mit einem Unternehmen zusammen, das ständig darum bemüht ist, etwas, IRGENDETWAS, zu tun, das die Effizienz steigert und besser wettbewerbsfähig ist. Sagen Sie Ihren Aktionären, dass wir "mehr vom Gleichen" tun werden, um ihre Umsatzziele zu erreichen? Diese Realität ist eher das Makrobild davon, warum Backend-Ingenieure jetzt CSS machen und warum sich das Frontend in den letzten Jahren so stark verändert hat.
Das heißt nicht, dass ich denke, dass Veränderung schlecht ist, oder dass nicht viel Gutes passiert ist. Es gab eine Menge toller Dinge. Auf der anderen Seite, einige der Ideen nicht so sehr... meiner Meinung nach, besonders in Bezug auf CSS. Natürlich kümmere ich mich um die Performance. Ich denke tatsächlich, dass das Problem, das Sie zu lösen versuchen, teilweise durch die Popularität der komponentenbasierte Entwicklung entstanden ist, was dazu geführt hat, dass viel CSS wiederholt wird. Persönlich nutze ich gerne eine Kombination aus BEM oder CSS Modules, zusammen mit einer gesunden Dosis des gefürchteten globalen CSS. Ich habe an ziemlich großen Codebasen mit mehreren Ingenieuren gearbeitet, die CSS bearbeiten (keine so groß wie Yahoo, gebe ich zu, aber es gibt nicht viele davon). Es ist eine Herausforderung, aber mit einem guten, disziplinierten System und jedem Beteiligten mit gutem Verständnis des Boxmodells, der Spezifität usw. glaube ich nicht, dass es viel mehr aufgebläht ist als Atomic CSS. Vergessen Sie nicht die Menge an Code, die Sie dem Markup hinzufügen. Vielleicht gibt es Einsparungen, wenn Sie alle die super minimalistische Kurzschriftversion verwenden, aber was ist der Kompromiss? Das Markup ist schrecklich schwer zu lesen, umständlich zu tippen, kein CSS-Linting, kein Emmet (ahh, einige stoppen die Presse hier!), keine Nutzung der riesigen Armada von CSS-Frameworks, Bibliotheken, Online-Pattern-Bibliotheken, CSS aus alten Projekten usw.
Es sei denn/bis Sie die gesamte Branche dazu bringen können, dies zu nutzen, wird es mein Leben und das vieler anderer erschweren, wenn sie darauf stoßen. Entschuldigung, wenn das negativ klingt, aber ich denke, es gibt andere und bessere Wege, um 20 oder so K zu sparen als das. Ich bin nicht gegen Sie, aber ich habe ein Recht auf meine Meinung, genau wie Sie.
Ich verzweifle. Was zur Hölle passiert in der Welt des Webs? Es ist, als ob alle verrückt geworden wären!
Machen diese Leute jemals ernsthafte Arbeit? Große Projekte sind nicht diejenigen mit viel Stil. Große Projekte sind diejenigen mit viel Inhalt, konsistent gestylt, die eine Marke liefern.
Welche verrückten Autoren ändern bei jedem neuen Projekt die Art und Weise, wie sie HTML verwenden? Nicht ich. Zum Beispiel mein geliebtes, treues, wiederverwendbares Formularmodul, das den HTML-Code für meine Formulare ausgibt, damit ich keine manuellen HTML-Formulare schreiben muss. Es leistet die harte Arbeit für mich, reduziert Fehler, gewährleistet Barrierefreiheit usw. Ich bin sicher, ich bin nicht der einzige Webprofi, der auf Komponenten angewiesen ist, um sein HTML zu generieren, viele Leute bearbeiten Mark Down und nicht HTML, zum Beispiel. Bearbeite ich trotzdem dieses HTML, wenn ich ein Formular mit anderem Design möchte? Nein! Warum sollte ich das tun? Das wäre absolut verrückt!
Wenn ich atomares CSS verwenden wollte, müsste ich genau das tun. Das ist eine massive Zeitverschwendung und eine unangemessene Verwendung von HTML und CSS. Wenn Sie atomares CSS in Erwägung ziehen, machen Sie etwas falsch und werden es noch schlimmer machen.
Ich denke, der Grund für die große Diskrepanz liegt darin, dass es davon abhängt, ob man eher Designer oder Frontend-Entwickler ist.
Als ich vor einem Jahr auf dieses Thema stieß, verstand ich auch nicht den Unterschied zwischen diesem und Inline-Stilen. Vor allem, da ich der einzige Designer im Team war.
Als sich jedoch meine Fähigkeiten veränderten und ich anfing, mehr auf der Programmierseite zu tun, begann ich zu verstehen, wie vorteilhaft ACSS ist. Zusätzlich begann ich, in größeren Teams und an komplexeren Projekten zu arbeiten.