[csswg-drafts] [selectors-4] Functional pseudo-class like :matches() with 0 specificity

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [selectors-4] Functional pseudo-class like :matches() with 0 specificity ==
## The problem

Sometimes, specificity is a blessing.  However, more often than not, it gets in the way, and authors have to resort to [hacks in order to artificially adjust specificity](https://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/), such as repeating classes (`.foo.foo.foo`), turning id selectors to attribute selectors (`[id=foo]` instead of `#foo`), or adding pointless `:not()`s (e.g. `.foo:not(.enough):not(.specificity)`). 

In the last few years, it has even become common to avoid selector logic altogether, just to avoid specificity woes. This is basically what conventions like [BEM](http://getbem.com/) are all about: turning combinators into a single class selector so that every selector has the same specificity and the cascade only goes top to bottom. For example, authors would write `.form__input--disabled` instead of `form input[disabled]`.

Specificity becomes an even bigger problem when authoring UI libraries, where you want your styles to be easy to override by the end author without them having to keep up with your stylesheet, but you still want to provide sensible defaults.

## Proposed solution

A new pseudo-class (name TBB) that works exactly like `:matches()` but with zero specificity. That way, authors have control over the specificity of their rules, and can choose what is best for their use case. 

Or, even `:matches()` itself, since it has not yet been implemented, and changing its specificity would solve #1027 as once.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1170 using your GitHub account

Received on Wednesday, 5 April 2017 00:33:39 UTC