Maybe I'm just old school because I learned CSS2 by reading the docs, and not as CSS in JS.
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.
.something {
.tells {
.me {
content: 'we do';
}
}
}
Also it's very powerful to extend a generic component:
Framework:
button.red { background: red; }
button.red.disabled { background: grey; } .something_else { .me: content 'we don't' }
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; }
It does seem that specificity isn't well understood, as I often see people abusing !important.
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.
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...
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/
That said, I also believe that CSS was the wrong solution to the wrong job: CSS addresses the DOM, not the UI, and does so with a kind of “multiple inheritance by default” approach, where an element will inherit properties via the cascade from many rules, until a rule that stops the cascade is written. Reasoning about what rules apply to what elements under what conditions becomes an exercise in extreme abstract thinking, and still there is another step to think about what the resulting UI that it will generate will look like. (I’ll leave off browser differences for now.)
If I find that I need to use the !important modifier, I’m usually being lazy.
Where I do tend to use it, is in print media styles, to force a style over CMS themes, which can be notoriously bad (for example, one of the themes I have used spews out multiple duplicate #ids. When I reported the bug, the response was basically “shrug Sucks to be you.” That was the least of the issues with the theme, and I was forced to use !important a few times).
:)
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.
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.
Of course, you can sometimes inherit a system that is one big specificity mess.
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 really sucks to have to jump in and work with some project's massive blob of vestigial, conflicting styles. )
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.