That’s right! And I can prove it, too. Let’s look at some CSS first:
.a {
color: red;
}
.b {
color: blue;
}
And now let’s look at some markup:
<div class="a b">Here’s some text</div>
The text is going to be blue because .b
is defined last in the CSS, right? But what if we go about and switch the order in which those classes are called in HTML:
<div class="b a">Here’s some text</div>
What color do you think the text should be? Red or blue?
This certainly might sound like a silly question but it tends to trip up a lot of folks who happen to be familiar with CSS-in-JS solutions. And this week I’ve spoken to two very senior front end engineers who thought similarly as well!
But the text in the example above will always be blue no matter what order those CSS classes are in. And that’s because the markup is just reading the CSS in the order that it’s written — the cascade wins in this example.
Indeed. DOMTokenList (or whatever the name is) is generally considered unordered.
It’s good form, however, to keep these sorts of things in the same order, particularly when using bootstrap or a similar model, due to compression and readability.
Because it’s CASCADE Style Sheet. The cascade order is what matters.
If we think that before HTML is shown, it loads the css first… so the will colorize the last loaded in the cascade file.
CSS always takes place from last to top and right to left so the ordering of the CSS matters not the classes in HTML.
Well, unless you go for [class^=”a”] that is.
You tripped me into believing you might be correct. Itried it in my browser… surprise surprise… it gives the same result
This make perfect sens. The CSS is interpreted (and cascading blah blah) not the html.
For style, it doesn’t matter. But what about Gzip and Brotli compression? Gzip compresses like-strings