114 ms·

I’m sure you know this, but for readers who don’t, it’s much more complex than “last defined wins with a few override options”. Based on “specificity”, rules ba

I’m sure you know this, but for readers who don’t, it’s much more complex than “last defined wins with a few override options”. Based on “specificity”, rules based on the selector used. Some examples: 1. #mydiv overrides .mydiv - IDs are more specific than classes 2. .outerdiv .innerdiv overrides .innerdiv - nested selectors are more specific 3. .mydiv overrides div - classes are more specific than elements And a lot of other rules. I can’t imagine I’d want this level of complexity in config files.

deleted 3y ago
[deleted]
masklinn 3y ago
Nesting is not actually more specific. Rather specificity is a triplet of (ids sub-selectors, class sub-selectors, element sub-selectors). When attributes conflict, the one whose rule has the more specific selector wins. The specificities of the rules you wrote out are (1,0,0), (0,1,0), (0,2,0), (0,1,0), (0,1,0), and (0,0,1). In-line attributes (@style) beat out out-out-of line ones except if they’re !important. Specificity also disambiguates between !important attributes.
- blowski 3y ago
  Thank you for the clarification, I hadn't realised that.
tobr 3y ago
> I can’t imagine I’d want this level of complexity in config files. Lots of people don’t want it in their CSS either. It’s generally considered good practice to make everything the same specificity and avoid !important.
- lavela 3y ago
  > avoid !important Sure, haven't seen that in a while in well structured code bases. > make everything the same specificity How would you achieve same specificity on everything? Only use either ids or classes? No type selectors / pseudo-classes / pseudo-elements / multiple selectors? I can't imagine how that would be feasible and am not aware of anyone recommending this.
  - Supermancho 3y ago
    There are a large number of companies that require ids as the basis for every selector, by policy. This may not be interesting to you, but I think this is what they meant. The fact they may or may not be familiar to you is incidental.
    - lavela 3y ago
      I'm familiar with policies that generally strive for specificity of (0, 1, 0) like BEM or (1, 0, 0), but I'd be very interested in any policy that rules out pseudo-classes like `:hover`, as prohibiting them would leave you to handle any interactivity you'd get for free from CSS via JavaScript.
      - blowski 3y ago
        This is effectively how Tailwind works. You end up with classes like `hover:text-black`.
  - afiori 3y ago
    With :is and :where it is trivial to trick selectors :is(selector_1, :where(selector_2)) Has always the specificity of selector_2, and if you choose an impossible selector for selector_1 (the easiest approach is to give multiple ids or use non existent classes/elements) it only select by selector_2
    - oneeyedpigeon 3y ago
      That looks far more complex than just using specificity properly as intended.
- cerved 3y ago
  Perhaps you mean the same kind of specificity. Specificity is at the heart of CSS, you're not supposed to design rules with equal specificity

deleted 3y ago

[deleted]

masklinn 3y ago

Nesting is not actually more specific. Rather specificity is a triplet of (ids sub-selectors, class sub-selectors, element sub-selectors). When attributes conflict, the one whose rule has the more specific selector wins. The specificities of the rules you wrote out are (1,0,0), (0,1,0), (0,2,0), (0,1,0), (0,1,0), and (0,0,1). In-line attributes (@style) beat out out-out-of line ones except if they’re !important. Specificity also disambiguates between !important attributes.

blowski 3y ago
Thank you for the clarification, I hadn't realised that.

tobr 3y ago

> I can’t imagine I’d want this level of complexity in config files. Lots of people don’t want it in their CSS either. It’s generally considered good practice to make everything the same specificity and avoid !important.

lavela 3y ago
> avoid !important Sure, haven't seen that in a while in well structured code bases. > make everything the same specificity How would you achieve same specificity on everything? Only use either ids or classes? No type selectors / pseudo-classes / pseudo-elements / multiple selectors? I can't imagine how that would be feasible and am not aware of anyone recommending this.
- Supermancho 3y ago
  There are a large number of companies that require ids as the basis for every selector, by policy. This may not be interesting to you, but I think this is what they meant. The fact they may or may not be familiar to you is incidental.
  - lavela 3y ago
    I'm familiar with policies that generally strive for specificity of (0, 1, 0) like BEM or (1, 0, 0), but I'd be very interested in any policy that rules out pseudo-classes like `:hover`, as prohibiting them would leave you to handle any interactivity you'd get for free from CSS via JavaScript.
    - blowski 3y ago
      This is effectively how Tailwind works. You end up with classes like `hover:text-black`.
- afiori 3y ago
  With :is and :where it is trivial to trick selectors :is(selector_1, :where(selector_2)) Has always the specificity of selector_2, and if you choose an impossible selector for selector_1 (the easiest approach is to give multiple ids or use non existent classes/elements) it only select by selector_2
  - oneeyedpigeon 3y ago
    That looks far more complex than just using specificity properly as intended.
cerved 3y ago
Perhaps you mean the same kind of specificity. Specificity is at the heart of CSS, you're not supposed to design rules with equal specificity