I feel like this article is just another:
"CSS is hard, and instead of learning, use this clever method that works for me."<p>Maybe I'm just old school because I learned CSS2 by reading the docs, and not as CSS in JS.
A rebuttal: <a href="https://codepen.io/davidkpiano/post/the-simplicity-of-specificity" rel="nofollow">https://codepen.io/davidkpiano/post/the-simplicity-of-specif...</a>
Using SASS or LESS makes specificity a great tool<p><pre><code> .something {
.tells {
.me {
content: 'we do';
}
}
}
</code></pre>
If you think of specificity as a kind of inheritance or scoping, then it makes a lot more sense.<p>Also it's very powerful to extend a generic component:<p>Framework:<p><pre><code> button.red { background: red; }
</code></pre>
User code:<p><pre><code> button.red.disabled { background: grey; }</code></pre>
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.)
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.<p>It does seem that specificity isn't well understood, as I often see people abusing !important.
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.
In my experience, very, <i>very</i> few Web designers actually use specificity <i>(UPDATE: I should have added "properly," as was pointed out)</i>.<p>It works extremely well, <i>if everyone follows the rules</i>, which is uncommon.<p>That goes for most of CSS; not just specificity.<p>CSS is incredibly powerful, if used properly, and specificity, when actually used properly, is very cool.<p>About ten years ago, I wrote this series: <a href="https://littlegreenviper.com/miscellany/stylist/introduction-to-specificity/" rel="nofollow">https://littlegreenviper.com/miscellany/stylist/introduction...</a><p>It’s still absolutely relevant nowadays, and just as few people follow that workflow now, as they did then.<p>CSS, in general, is too complicated (IMNSHO), but that complexity is also what makes it so powerful.<p>I’ve always enjoyed Stu Nicholls’ CSSPlay site, for examples of extreme CSS: <a href="http://www.cssplay.co.uk/menu/" rel="nofollow">http://www.cssplay.co.uk/menu/</a>
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.
Nice.<p>Facepalm slap. Just like other matching algorithms. How did I not notice that earlier?<p>Order independent specificity is like longest match rules. Regex, lexing, URL routers, etc.<p>Order dependent matching overrides (correct phrase?) is like Packrat & PEG.<p>Which is better depends on ambiguity, meaning how well your "matcher" algorithm can process whatever input you have.<p>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.
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.<p>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.
The simple solution is delete before you add more specificity. Cut it back to the common denominator and cascade from there.<p>Of course, you can sometimes inherit a system that is one big specificity mess.
<p><pre><code> 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.
</code></pre>
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.
I really admire <a href="http://tachyons.io" rel="nofollow">http://tachyons.io</a>, with its principles of <i>shallow cascade</i> and <i>low specificity</i>.<p>( It really sucks to have to jump in and work with some project's massive blob of vestigial, conflicting styles. )
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!<p>There is however a small problem if you want to use many CSS files - that you need to link them in the correct order.<p>edit: Also I don't use ID's in CSS.