8 ms·

Do We Need Specificity in CSS? (2015)

41 points by edjroot 6y ago

Etheryte 6y ago
While this is an interesting thought experiment, and the outlined problem is a real issue, I don't think the outlined solution is a good way to resolve it. The main problem here is predictability: maybe it's simply that I'm not used to thinking about CSS this way, but the proposed CSS rewriting parser means it's not immediately obvious how what I write maps to the end result. It's entirely possible that I'm missing some of the benefit here, but it seems to me that scoped styles etc largely already solve this problem.
ryannevius 6y ago
A rebuttal: https://codepen.io/davidkpiano/post/the-simplicity-of-specificity https://codepen.io/davidkpiano/post/the-simplicity-of-specif...
- davidkpiano 6y ago
  Oh wow, I barely remember writing this 4+ years ago! I still hold to it - specificity is a necessary mechanism, and if it's hard, it's because we're unnecessarily over-complicating it, just like anything else considered "hard" if we misuse it.
dwd 6y ago
The simple solution is delete before you add more specificity. Cut it back to the common denominator and cascade from there. Of course, you can sometimes inherit a system that is one big specificity mess.
mehrdadn 6y ago
Warnings seem like the way to go for this? i.e. having a static analyzer to check that the specificity matches the declaration order. (Assuming that's possible... it's not obvious to me if there are theoretical roadblocks.)
- deleted 6y ago
  [deleted]
- stefanfisk 6y ago
  Stylelint actually has this already! https://stylelint.io/user-guide/rules/no-descending-specificity https://stylelint.io/user-guide/rules/no-descending-specific...
z3t4 6y ago
I always write the specificity in the same order as the cascade. Could probably write a tool that compares the specificity vs the cascade to find errors! There is however a small problem if you want to use many CSS files - that you need to link them in the correct order. edit: Also I don't use ID's in CSS.
bestest 6y ago
Specificity and cascading become redundant once we talk css modules. I work with CSS modules so I can't remember the last time I had to_ cascade_ style sheets, or _think_ about specificity.
ChrisMarshallNY 6y ago
In my experience, very, very few Web designers actually use specificity (UPDATE: I should have added "properly," as was pointed out). It works extremely well, if everyone follows the rules, which is uncommon. That goes for most of CSS; not just specificity. CSS is incredibly powerful, if used properly, and specificity, when actually used properly, is very cool. About ten years ago, I wrote this series: https://littlegreenviper.com/miscellany/stylist/introduction-to-specificity/ https://littlegreenviper.com/miscellany/stylist/introduction... It’s still absolutely relevant nowadays, and just as few people follow that workflow now, as they did then. CSS, in general, is too complicated (IMNSHO), but that complexity is also what makes it so powerful. I’ve always enjoyed Stu Nicholls’ CSSPlay site, for examples of extreme CSS: http://www.cssplay.co.uk/menu/ http://www.cssplay.co.uk/menu/
- tiborsaas 6y ago
  I find this really hard to believe. Specificity is baked into CSS at such a fundamental level that you can't not use it. Maybe you meant like they don't use it consciously of effectively?
  - ChrisMarshallNY 6y ago
    Fair ‘nuff. People don’t use it consciously, so my statement was not specific enough. :)
  - ZenPsycho 6y ago
    there’s using it deliberately as a tool, and running into it unexpectedly and doing absurd things to work around it like it’s an obstacle to overcome. i see much more of the latter than the former; squarely i think because most css is written by people who don’t know how to use specificity - so they come up with things like BEM, or css in js frameworks to force specificity away like it’s a flaw in the system. all this work goes in because module scope is an easier mental model to grasp than specificity, which i suppose works more like traits. but, having been in this web making game long enough, it seems like a return to table based design and font tags. just with different syntax.
tiborsaas 6y ago
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 6y ago
  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 6y ago
    exactly. more specific selectors are edge cases, which is a usually-acceptable heuristic for rule priority but doesn't correspond 1:1.
- woodrowbarlow 6y ago
  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 6y ago
    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?
deleted 6y ago
[deleted]
CerebralCerb 6y ago
Specificity isn’t intuitive, and—especially for new developers—the results can often seem like a gotcha rather than the intended behavior. I’m also not sure there’s an equivalent in other systems or languages. It is widely used as a conflict resolution strategy in production systems. I've never encountered a student who found specificity to be a difficult concept to grasp.
yohannparis 6y ago
I feel like this article is just another: "CSS is hard, and instead of learning, use this clever method that works for me." Maybe I'm just old school because I learned CSS2 by reading the docs, and not as CSS in JS.
- HelloNurse 6y ago
  Not only approaching the "problem" of learning CSS by eliminating things to learn, but starting from bad assumptions (e.g. that combining stylesheets is a problem and not a solution) and never questioning them.
deleted 6y ago
[deleted]
amflare 6y ago
I feel like source order should be the thing that is done away with. Specificity allows me to style something, and trust that style will style correctly no matter what my build system does, or what order my stylesheets load, or what my co-worker adds later for their fancy new CTA button.
specialist 6y ago
Nice. Facepalm slap. Just like other matching algorithms. How did I not notice that earlier? Order independent specificity is like longest match rules. Regex, lexing, URL routers, etc. Order dependent matching overrides (correct phrase?) is like Packrat & PEG. Which is better depends on ambiguity, meaning how well your "matcher" algorithm can process whatever input you have. I've done my fair share of scraping. (I usually default to my own globbing implementation. Generally more simple than xpath or css expressions.) Now I'm feeling pretty stupid that I'd always hard-coded precedence resolution.
atrilumen 6y ago
I really admire http://tachyons.io http://tachyons.io, with its principles of shallow cascade and low specificity. ( It really sucks to have to jump in and work with some project's massive blob of vestigial, conflicting styles. )
calibas 6y ago
I maintain sites with thousands of CSS rules and over a dozen style sheets, some of which are hosted on external domains that I have no control over. Having to manage CSS rules based upon order would be a nightmare. It does seem that specificity isn't well understood, as I often see people abusing !important.
- cryptica 6y ago
  Agreed. The article claims that "Importance also makes a lot of sense" but actually, the way it was implemented in CSS makes no sense because eventually, given a sufficiently old stylesheet, all styles end up being marked with !important and then you're back to relying on source-ordering.
timwis 6y ago
But what if you put your styles in multiple files?

41 points by edjroot 6y ago

While this is an interesting thought experiment, and the outlined problem is a real issue, I don't think the outlined solution is a good way to resolve it. The main problem here is predictability: maybe it's simply that I'm not used to thinking about CSS this way, but the proposed CSS rewriting parser means it's not immediately obvious how what I write maps to the end result. It's entirely possible that I'm missing some of the benefit here, but it seems to me that scoped styles etc largely already solve this problem.

ryannevius 6y ago

A rebuttal: https://codepen.io/davidkpiano/post/the-simplicity-of-specificity https://codepen.io/davidkpiano/post/the-simplicity-of-specif...

davidkpiano 6y ago
Oh wow, I barely remember writing this 4+ years ago! I still hold to it - specificity is a necessary mechanism, and if it's hard, it's because we're unnecessarily over-complicating it, just like anything else considered "hard" if we misuse it.

dwd 6y ago

The simple solution is delete before you add more specificity. Cut it back to the common denominator and cascade from there. Of course, you can sometimes inherit a system that is one big specificity mess.

mehrdadn 6y ago

Warnings seem like the way to go for this? i.e. having a static analyzer to check that the specificity matches the declaration order. (Assuming that's possible... it's not obvious to me if there are theoretical roadblocks.)

deleted 6y ago
[deleted]
stefanfisk 6y ago
Stylelint actually has this already! https://stylelint.io/user-guide/rules/no-descending-specificity https://stylelint.io/user-guide/rules/no-descending-specific...

z3t4 6y ago

I always write the specificity in the same order as the cascade. Could probably write a tool that compares the specificity vs the cascade to find errors! There is however a small problem if you want to use many CSS files - that you need to link them in the correct order. edit: Also I don't use ID's in CSS.

bestest 6y ago

Specificity and cascading become redundant once we talk css modules. I work with CSS modules so I can't remember the last time I had to_ cascade_ style sheets, or _think_ about specificity.

ChrisMarshallNY 6y ago

In my experience, very, very few Web designers actually use specificity (UPDATE: I should have added "properly," as was pointed out). It works extremely well, if everyone follows the rules, which is uncommon. That goes for most of CSS; not just specificity. CSS is incredibly powerful, if used properly, and specificity, when actually used properly, is very cool. About ten years ago, I wrote this series: https://littlegreenviper.com/miscellany/stylist/introduction-to-specificity/ https://littlegreenviper.com/miscellany/stylist/introduction... It’s still absolutely relevant nowadays, and just as few people follow that workflow now, as they did then. CSS, in general, is too complicated (IMNSHO), but that complexity is also what makes it so powerful. I’ve always enjoyed Stu Nicholls’ CSSPlay site, for examples of extreme CSS: http://www.cssplay.co.uk/menu/ http://www.cssplay.co.uk/menu/

tiborsaas 6y ago
I find this really hard to believe. Specificity is baked into CSS at such a fundamental level that you can't not use it. Maybe you meant like they don't use it consciously of effectively?
- ChrisMarshallNY 6y ago
  Fair ‘nuff. People don’t use it consciously, so my statement was not specific enough. :)
- ZenPsycho 6y ago
  there’s using it deliberately as a tool, and running into it unexpectedly and doing absurd things to work around it like it’s an obstacle to overcome. i see much more of the latter than the former; squarely i think because most css is written by people who don’t know how to use specificity - so they come up with things like BEM, or css in js frameworks to force specificity away like it’s a flaw in the system. all this work goes in because module scope is an easier mental model to grasp than specificity, which i suppose works more like traits. but, having been in this web making game long enough, it seems like a return to table based design and font tags. just with different syntax.

tiborsaas 6y ago

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 6y ago
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 6y ago
  exactly. more specific selectors are edge cases, which is a usually-acceptable heuristic for rule priority but doesn't correspond 1:1.
woodrowbarlow 6y ago
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 6y ago
  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?

deleted 6y ago

[deleted]

CerebralCerb 6y ago

Specificity isn’t intuitive, and—especially for new developers—the results can often seem like a gotcha rather than the intended behavior. I’m also not sure there’s an equivalent in other systems or languages. It is widely used as a conflict resolution strategy in production systems. I've never encountered a student who found specificity to be a difficult concept to grasp.

yohannparis 6y ago

I feel like this article is just another: "CSS is hard, and instead of learning, use this clever method that works for me." Maybe I'm just old school because I learned CSS2 by reading the docs, and not as CSS in JS.

HelloNurse 6y ago
Not only approaching the "problem" of learning CSS by eliminating things to learn, but starting from bad assumptions (e.g. that combining stylesheets is a problem and not a solution) and never questioning them.

deleted 6y ago

[deleted]

amflare 6y ago

I feel like source order should be the thing that is done away with. Specificity allows me to style something, and trust that style will style correctly no matter what my build system does, or what order my stylesheets load, or what my co-worker adds later for their fancy new CTA button.

specialist 6y ago

Nice. Facepalm slap. Just like other matching algorithms. How did I not notice that earlier? Order independent specificity is like longest match rules. Regex, lexing, URL routers, etc. Order dependent matching overrides (correct phrase?) is like Packrat & PEG. Which is better depends on ambiguity, meaning how well your "matcher" algorithm can process whatever input you have. I've done my fair share of scraping. (I usually default to my own globbing implementation. Generally more simple than xpath or css expressions.) Now I'm feeling pretty stupid that I'd always hard-coded precedence resolution.

atrilumen 6y ago

I really admire http://tachyons.io http://tachyons.io, with its principles of shallow cascade and low specificity. ( It really sucks to have to jump in and work with some project's massive blob of vestigial, conflicting styles. )

calibas 6y ago

I maintain sites with thousands of CSS rules and over a dozen style sheets, some of which are hosted on external domains that I have no control over. Having to manage CSS rules based upon order would be a nightmare. It does seem that specificity isn't well understood, as I often see people abusing !important.

cryptica 6y ago
Agreed. The article claims that "Importance also makes a lot of sense" but actually, the way it was implemented in CSS makes no sense because eventually, given a sufficiently old stylesheet, all styles end up being marked with !important and then you're back to relying on source-ordering.

timwis 6y ago

But what if you put your styles in multiple files?