Das ist richtig! Und ich kann es auch beweisen. Schauen wir uns zuerst etwas CSS an
.a {
color: red;
}
.b {
color: blue;
}Und nun schauen wir uns das Markup an
<div class="a b">Here’s some text</div>Der Text wird blau, weil .b zuletzt in CSS definiert ist, richtig? Aber was ist, wenn wir die Reihenfolge der Klassen im HTML ändern?
<div class="b a">Here’s some text</div>Welche Farbe soll der Text Ihrer Meinung nach haben? Rot oder blau?
Das mag sicherlich wie eine dumme Frage klingen, aber es verwirrt viele Leute, die mit CSS-in-JS-Lösungen vertraut sind. Und diese Woche habe ich mit zwei sehr erfahrenen Front-End-Entwicklern gesprochen, die ebenfalls ähnlich dachten!
Aber der Text im obigen Beispiel wird immer blau sein, egal in welcher Reihenfolge diese CSS-Klassen stehen. Und das liegt daran, dass das Markup einfach den CSS in der Reihenfolge liest, in der er geschrieben ist – die Kaskade gewinnt in diesem Beispiel.
In der Tat. DOMTokenList (oder wie auch immer der Name ist) wird generell als ungeordnet betrachtet.
Es ist jedoch gute Praxis, diese Dinge in der gleichen Reihenfolge zu halten, insbesondere bei der Verwendung von Bootstrap oder einem ähnlichen Modell, aus Gründen der Kompression und Lesbarkeit.
Weil es Kaskadierende Style Sheets sind. Die Reihenfolge der Kaskade zählt.
Wenn wir denken, dass das CSS zuerst geladen wird, bevor das HTML angezeigt wird… dann wird das zuletzt geladene im Kaskadenfile gefärbt.
CSS wird immer von unten nach oben und von rechts nach links angewendet, daher zählt die Reihenfolge des CSS, nicht die der Klassen im HTML.
Nun, es sei denn, Sie wählen [class^=”a”].
Sie haben mich dazu gebracht zu glauben, Sie hätten Recht. Ich habe es in meinem Browser ausprobiert… Überraschung, Überraschung… es ergibt das gleiche Ergebnis
Das ergibt perfekt Sinn. Das CSS wird interpretiert (und die Kaskade blablabla), nicht das HTML.
Für den Stil spielt das keine Rolle. Aber was ist mit Gzip- und Brotli-Kompression? Gzip komprimiert ähnliche Strings