Eine der Herausforderungen, denen wir bei der Implementierung von atomarem Styling auf Basis von Klassen gegenüberstehen, ist, dass es oft einen spezifischen Breakpoint für den Kontext benötigt.
<div class="span-12"></div> <!-- we want this for small screens -->
<div class="span-6"></div> <!-- we want this for medium screens -->
<div class="span-4"></div> <!-- we want this for large screens -->
Es ist üblich, ein Präfix zu verwenden, um jeden Breakpoint zu adressieren
<div class="sm-span-12 md-span-6 lg-span-4"></div>
Das funktioniert gut, bis wir anfangen, mehrere Klassen hinzuzufügen. Dann wird es schwierig, den Überblick zu behalten, was zu was gehört und wo etwas hinzugefügt, entfernt oder geändert werden muss.
<div class="
sm-span-12
md-span-6
lg-span-4
sm-font-size-xl
md-font-size-xl
lg-font-size-xl
md-font-weight-500
lg-font-weight-700">
</div>
Wir können versuchen, es lesbarer zu machen, indem wir es neu gruppieren
<div class="
sm-span-12
sm-font-size-xl
md-span-6
md-font-size-xl
md-font-weight-500
lg-span-4
lg-font-size-xl
lg-font-weight-700">
</div>
Wir können schicke Trennzeichen hinzufügen (ungültige Klassennamen werden ignoriert)
<div class="
[
sm-span-12
sm-font-size-xl
],[
md-span-6
md-font-size-xl
md-font-weight-500
],[
lg-span-4
lg-font-size-xl
lg-font-weight-700
]">
</div>
Aber das fühlt sich immer noch unordentlich und schwer fassbar an, zumindest für mich.
Wir können einen besseren Überblick bekommen und Implementierungspräfixe vermeiden, indem wir Attributselektoren anstelle von tatsächlichen Klassen gruppieren
<div
data-sm="span-12 font-size-lg"
data-md="span-6 font-size-xl font-weight-500"
data-lg="span-4 font-size-xl font-weight-700"
>
</div>
Dies sind keine verlorenen Klassen, sondern eine durch Leerzeichen getrennte Liste von Attributen, die wir mit [attribute~="value"] auswählen können, wobei ~= erfordert, dass das exakte Wort im Attributwert gefunden wird, um übereinzustimmen.
@media (min-width: 0) {
[data-sm~="span-1"] { /*...*/ }
[data-sm~="span-2"] { /*...*/ }
/* etc. */
}
@media (min-width: 30rem) {
[data-md~="span-1"] { /*...*/ }
[data-md~="span-2"] { /*...*/ }
/* etc. */
}
@media (min-width: 60rem) {
[data-lg~="span-1"] { /*...*/ }
[data-lg~="span-2"] { /*...*/ }
/* etc. */
}
Es mag etwas seltsam aussehen, aber ich denke, die Übersetzung von atomaren Klassen in Attribute ist ziemlich unkompliziert (z.B. .sm-span-1 wird zu [data-sm~="span-1"]). Außerdem haben Attributselektoren die gleiche Spezifität wie Klassen, also verlieren wir dort nichts. Und im Gegensatz zu Klassen können Attribute ohne Escaping von Sonderzeichen geschrieben werden, wie /+.:?.
Das ist alles! Auch hier handelt es sich lediglich um eine Idee, die darauf abzielt, den Austausch von Deklarationen in Media Queries einfacher zu schreiben, zu lesen und zu verwalten. Es ist definitiv kein Vorschlag, Klassen oder ähnliches abzuschaffen.
Ja, es mag leichter zu lesen sein, aber es ist kein gültiges HTML. Für eine Seite wie CSS Tricks, die viele Leser und einen riesigen Einfluss hat, sollte etwas wie das mit einer Art Warnung oder Haftungsausschluss versehen sein, damit das Publikum dies nicht implementiert, ohne die Konsequenzen zu kennen.
Hm, ja, das sollten
data-*Attribute sein. Entschuldigen Sie das, ich werde es korrigieren.Warum denkst du, dass es ungültiges HTML ist?
Die Spezifikation besagt, dass Datenattribute sogar gültiges XML sind
https://www.w3.org/TR/2011/WD-html5-20110525/elements.html#attr-data
Obwohl ich denke, dass das HTML gültig ist, weiß ich nicht, ob es klug ist, es so zu verwenden. Gibt es irgendwelche Leistungseinbußen bei der Verwendung von Find-in-Attribute-Selektoren anstelle von spezifischen Klassen?
Außerdem finde ich die Attributselektor-CSS weniger angenehm zu lesen als herkömmliche Klassen. Vielleicht ist das nur eine Frage der Gewöhnung.
@J.T.: Als der Artikel zum ersten Mal veröffentlicht wurde, waren es noch keine
data-Attribute — Chris hat sie nach meinem Kommentar sehr schnell hinzugefügt, also Hut ab vor ihm :)HTML-Attribute wie
myAttribute="value"werden von Browsern ignoriert, wenn sie nicht in den WC3-Spezifikationen enthalten sind, aber sie funktionieren als CSS-Selektoren. Das Hinzufügen desdata-Präfixes stellt sicher, dass es keine Konflikte gibt, wennmyAttributein Zukunft als offizielles Attribut eingeführt wird.Ich hoffe, das hilft, den Fokus wieder auf die Absicht des Artikels zu lenken :)
~ Jakob
Das ist genial, Mann, das gefällt mir!
Erstaunliche Idee des Tages, werde sie auch in meinen Projekten verwenden.
Es ist wirklich ein guter Weg, dynamisches Templating innerhalb von Responsive Design anzuwenden. Danke fürs Teilen.
Aus Spezifitätssicht kann dies definitiv durch standardmäßige klassenbasierte Grids ersetzt werden, da Attributselektoren gleich Klassen-Selektoren sind.
Aber das Erstellen von Webseiten mit dem Ansatz des atomaren Stylings hat einfach diesen Nebeneffekt, dass Klassen überwältigend groß werden (meiner Meinung nach).
Deshalb bevorzuge ich persönlich den BEM-Ansatz, da es im DOM nicht so viele Klassen wie beim atomaren Styling gibt und das DOM viel lesbarer und semantischer ist.
Seien Sie nur vorsichtig, dass ~=’span-1′ auch span-10, span-11 und span-12 übereinstimmt. Wenn Sie dies verwenden, erwarten Sie also einige Überlappungen und achten Sie auf Seltsamkeiten.
Hallo Shea,
Dies ist nur der Fall, wenn Sie
*=verwenden. Die~=erfordert eine exakte Wertübereinstimmung (keine Leerzeichen).Beispiel
~ Jakob
Sehr gut. Gut zu sehen, dass auch andere Leute anfangen, Attributselektoren zu verwenden. Ich benutze sie in letzter Zeit viel zum Prototyping, auch ohne data-Präfix. Hier ist ein Beispiel: https://codepen.io/mikemai2awesome/pen/58903b18084725268a30609ff6528cd3
Ich bin neugierig, verursachen diese Arten von Selektoren einen spürbaren Performance-Hit? Ich hätte gedacht, dass die Übereinstimmung von Klassennamen stark optimiert ist.