[no_wizard]

I have been writing a lot of CSS (well SCSS) lately and this seems like a good time as any (though I admit somewhat off topic) about a question I have regarding the newer Combination & Multiple selectors https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduct... and Attribute Selectors https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduct...

This stems from the fact that I have inherited the task of re-writing a very large (at least for one person, I feel) task of re-writing an internal framework that is really gotten too burdensome to add anything to. I have been contemplating instead of trying to get crazy with a ton of different selectors where you end up with a pattern like this:

``` .selector .selector1 li, .selector .selector1 li a { some-style: some-value; } ```

Which I find A little crazy compared to something like this:

``` [class*="selector selector1] { some-style: some value; } ```

or my person favorite:

``` ul > li > a { color: blue; } ```

While these examples are I think very simplistic (I don't wanna junk up the page with tons of stuff) I've met alot of resistance to this idea, and splunking other frameworks for inspiration (Shout out to https://bulma.io ! I like their work, its really wonderful FYI.) I don't see alot of this.

While the resistance I've met from others who have some input on this project (and rightly so, they're also part of our stellar in house design team) seem to resist this idea, but haven't articulated why.

I was wondering if it comes down to: is there actually an issue with using these heavily vs some of the older semantics or, which I feel is quite possible, people have done things for so long one way its hard to see another way?

While its seemingly less verbose sometimes (not always) I feel like the new selectors give you a way to combat specificity problems by controlling when context around your classes is better than having ton of different classes and nesting those over and over.

Am i missing something?

[jacobwilliamroy]

Generally you would want to avoid descendant and child selectors. With rules like

  ul > li > a

  .selector .selector1 li a

The system will check ALL anchor tags and move left until it has completely matched the rule. This makes the above selectors extremely expensive (perfomance-wise) and can cause slow page-loads. Tag selectors and universal selectors are generally a bad idea for this same reason.

And using inheritance to select elements indirectly is actually better for performance than directly selecting the inheriting elements. For example, if you want to set typography for an entire page, instead of selecting all p and h1 tags, just select the body tag.

Here's a link to a more in-depth explanation of all of the above with examples:

http://mdn.beonex.com/en/CSS/Writing_Efficient_CSS.html

[esprehn]

The good news is all modern browsers use a Bloom Filter to quickly skip over elements that wouldn't match the descendant or child selector relationship.

You could probably construct situations with very deep selector relationships and thousands of matching elements where the ancestor walking adds up but the other costs of computing style often end up being more important than the selector matching in many scenarios. Not that you shouldn't aim for simpler selectors of course.

(Usually the problems with expensive selectors come from side effects of dynamic changes to the document. ex. Some selectors will make the browser recompute hundreds of elements when only changing something small because the browser isn't tracking that relationship in a precise way.)

[no_wizard]

Hmm so what’s consensus then? Avoid these types of selectors when at all possible or no?