Stefan Judis, two days before I mouthed off about using (X, X, X, X) for talking about specificity, has a great blog post not only using that format, but advocating that browser DevTools should show us that value by selectors.
I think that the above additions could help to educate developers about CSS tremendously. The only downside I can think of is that additional information might overwhelm developers, but I would take that risk in favor of more people learning CSS properly.
I’d be for it. The crossed-off UI for the “losing” selectors is attempting to teach this, but without actually teaching it. I wouldn’t be that worried about the information being overwhelming. I think if they are considerate about the design, it can be done tastefully. DevTools is a very information-dense place anyway.
I think Specificity Notation is a good communication tool as long as devs can reconcile the notation in their IDEs with the final output in production.
If you’re using SCSS on a large scale project, the specificity between dev and production probably isn’t 1:1. If you’re using CSS modules or a CSS in JS solution, the specificity for your app is probably (mostly) flat because adding UUIDs to class names is a more reliable way to prevent style collisions.
If you’re working with shadow DOM, well, specificity is relative to which side of the fence you’re on.
If specificity notation is so overwhelming that it might drive people away from front-end dev, do you really want those developers working on your software?
It seems like a good idea to me too. Historically, I’ve never had much trouble knowing the specificity of a selector at a glance, but with the newer rules around :is(), :where() and :not(), when you’ve got a combination of them in a selector, they’re not so easy to evaluate. An indicator in the dev tools could provide good guidance.