Ich arbeitete mit CSS Grid und stieß auf die Eigenschaften grid-column und grid-row. Ich hielt einen Moment inne.
Sie sind nicht übermäßig kompliziert. Es sind Kurzhand-Eigenschaften, um auszudrücken, wo ein Element auf den definierten Spalten und Zeilen eines Rasters beginnen und enden soll.
Was mich faszinierte, war die Tatsache, dass ich diese Linien benennen *kann*. Es ist keine Anforderung (man kann Zahlen verwenden), aber die Möglichkeit, Rasterlinien zu benennen, ist etwas, das wir hier tun können. Tatsächlich kann die Benennung von Linien zu raffinierten CSS-Tricks führen.
Rasterlinien sind ein weiterer Punkt auf einer langen Liste von Beispielen, bei denen Front-End-Entwickler die Macht haben, Dinge zu benennen. Klassennamen und IDs waren schon immer Dinge, die wir in CSS benennen müssen, aber betrachten wir einige der historisch jüngeren Dinge, bei denen die Benennung für das Styling wichtig ist:
- Variablen: Benennung von Werten zur Kontextualisierung, wie wiederverwendbare Farben oder numerische Werte, sei es in Präprozessoren oder neuen CSS-Variablen.
- Datenattribute: Elemente auswählen basierend auf ihren HTML-Attributen anstelle eines Klassennamens.
- Komponenten: Wie wir in React und zukünftigen CSS-Features wie Web Components sehen.
- CSS-Dateien: Organisationsmethoden wie Atomic Design haben die Bedeutung der Benennung unserer Dateien, einschließlich Präprozessor-Partials, betont.
- Media Queries: Wir wissen, dass die Benennung nach Geräten zwecklos ist, also muss auch das Sinn ergeben.
Es ist nicht so, dass die Benennung von Dingen an sich lächerlich schwierig ist. Es ist vielmehr so, dass mit der Fähigkeit, Dinge zu benennen, eine Art von Macht einhergeht. Wie das Sprichwort sagt: Mit großer Macht kommt große Verantwortung. In diesem Fall hat die Benennung Auswirkungen auf alles, von der Art und Weise, wie Code geschrieben und organisiert wird, bis hin zu seiner Gesamtleistung und Wartbarkeit. Schlecht benannte Elemente sind von Natur aus stinkend und oft ein Indikator für die Gesamtqualität des Codes. Es kann zu der Befürchtung eines wachsenden Codebestands führen.
Sagen wir einfach, ich habe mehr Zeit damit verbracht, einige CSS-Klassen zu benennen, als meine eigenen beiden Kinder zu benennen. Ich schäme mich, das zu sagen, aber es ist die Wahrheit.
Die Benennung von Rasterlinien ist nur ein weiterer Punkt in der wachsenden Kaskade von Dingen, für die wir als Front-End-Entwickler verantwortlich sind. Es ist nichts Schlechtes oder auch nur Ärgerliches, sondern nur eine weitere Erinnerung daran, wie Front-End-Entwicklung Entwicklung, Design und Architektur in einem ist.
Ich glaube, dieser Beitrag unterschätzt, wie schwer und wichtig die Benennung von Dingen ist. Wenn man die meisten Entwickler, ob Front- oder Backend, mit einer Stoppuhr beobachten würde, würde ich wetten, dass 20 % oder mehr ihrer Zeit für die Benennung von Dingen aufgewendet werden. Nicht nur das, sondern ich würde wetten, dass 80 % der Zeit, die für das Lesen von Code aufgewendet wird, für das Lesen dieser Namen aufgewendet würde. Ich habe das Gefühl, dass nicht die Benennung von Dingen schwieriger wird, sondern dass die eigentliche Logik unserer Arbeit in wiederverwendbare Lego-ähnliche Teile abstrahiert wird, und jedes dieser Teile braucht Namen.
Zustimmung, die Abstraktion und die Bedeutung der Benennung dieser Lego-Teile ist genau das, was Sache ist. Der Punkt ist nicht, dass die Benennung von Dingen nicht schwer ist oder vorher nicht schwer war, sondern dass sie im Laufe der Zeit nur immer schwieriger und wichtiger wird.
Vor einigen Jahren habe ich eine CSS-Namensmethodik entwickelt (hauptsächlich für mich selbst), aber vielleicht können Sie einige Dinge davon gebrauchen?
https://github.com/kevinvanhove
Kevin,
@Kevin,
Deine Github-Quelle ist sehr nützlich, vielen Dank.
-Dominique
Sehr cool! Danke, Kevin. :)
Hier ist, was ich mir bezüglich der Konventionen für die Benennung von Breakpoints überlegt habe. Die Größen sind Mobile First, d.h. null und aufwärts. Jeder bp ist ein Bereich, in dem die gängigste Gerätegröße normalerweise etwa in der Mitte liegt, sodass wir ähnliche Geräte nach bp-Gruppen gruppieren.
mobile: 0px // Mobile First, d.h. null und aufwärts
tablet-v: 600px // Ziel 768
tablet-h: 900px // Ziel 1024
laptop: 1200px // Ziel 1366
desktop: 1600px // Ziel 1920 und höher
Hoffentlich wird jeder, der diesen Code verwendet, ihn ziemlich selbsterklärend finden.