[tiborsaas]

Using SASS or LESS makes specificity a great tool

    .something { 
         .tells {
              .me {
                  content: 'we do';
              }
         }
    }

If you think of specificity as a kind of inheritance or scoping, then it makes a lot more sense.

Also it's very powerful to extend a generic component:

Framework:

    button.red { background: red; }

User code:

    button.red.disabled { background: grey; }

[d_watt]

For me, it's actually the exact opposite. When I use scoping like that, my normal expectation is that I'm saying "Only style .me if it's in a .tells that's in a .something". I'm doing it for selector behavior. I don't want to have to consider if I later scope a

  .something_else { .me: content 'we don't' }

it won't work because it's less specific, meaning cascading isn't working as expected. It isn't SOLID

[woodrowbarlow]

exactly. more specific selectors are edge cases, which is a usually-acceptable heuristic for rule priority but doesn't correspond 1:1.

[woodrowbarlow]

i think the fact that specificity isn't scoped is where it causes problems.

let's say i include a CSS reset, and then include my CSS file. if i put this in my CSS file, suddenly i'm competing (and losing) against an external dependency:

    input { padding: 0.5em; }

if all CSS conflicts were resolved as "last declared wins" (rather than specificity), i feel we'd be a lot better off in terms of organized, maintainable CSS. we'd be breaking things into more files than we do today, but i think "pruning" would be a more approachable task.

[prashnts]

Not so sure that “last declaration wins” would be great — a very specific example: jupyter notebooks (used to?) add custom.css before the original stylesheet. It’d be impossible if that were the case, I guess?

[woodrowbarlow]

why? custom.css would still be loaded, just that if any rules conflict between the two, the original stylesheet would win.

if custom.css makes some text bold and red, and then a second stylesheet comes along and makes the text blue, the final text would be bold and blue.

but with CSS specificity defining priority, whether the text is blue or red depends on which file has the gnarliest, most complicated selector.

custom.css could be put after the original instead of before if you want the custom rules to win.

[prashnts]

Ah, thanks for the explanation -- I thought that you meant that custom.css would be disregarded, now I see you meant that css _rules_ should use "last declaration wins".

Not really a followup on my previous question: what would be done if, say one can't change the order: so custom.css is still before original css. In such cases, without the specificity rule, wouldn't the only option we'd have is to somehow inline the styles, or spray !important everywhere?

To be clear, I only ever did this once for jupyter, and using very specific selectors was the only way I could do it -- of course I learned it hard way why this approach isn't great when jupyter changed the layout slightly. :)

If you're curious, https://github.com/prashnts/dotfiles/blob/0a2e98a848a98b7010... is that custom.css

[woodrowbarlow]

that's true, but that's pretty much the experience of writing userstyles anyway. i remember back in the greasemonkey days, their built-in editor even had an option to automatically append `!important` to every line when you click save.