W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2017

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

From: Lea Verou via GitHub <sysbot+gh@w3.org>
Date: Fri, 15 Sep 2017 18:52:16 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-329869487-1505501525-sysbot+gh@w3.org>
One potential name for this could be `:filter()`.

A common use case for me is `:not()`. The default specificity rules on `:not()` are almost never helpful. One often includes lots of filters, one after the other, but that increases specificity and makes these rules hard to override. E.g. good luck overriding `div:not(#foo):not(#bar):not(#baz)` in a sane way, even though this selector is essentially as general as `div` minus three specific divs.

The [default Mavo stylesheet](https://github.com/mavoweb/mavo/blob/master/src-css/mavo.scss) has many good examples of this. It's a stylesheet that's meant to be easy to override, and in practice, authors have to artificially increase specificity of their rules to override it because I had to be very conservative in what is styled so the selectors have to be very specific. However, being specific doesn't always mean they are high priority.

All in all, specificity is a heuristic. It's assuming that it can deduce rule priority from the selector, but the selector is not expressing priority, it's expressing a query. Heuristics are very helpful when they are correct, but a PITA when they fail, so there always needs to be a way to override them. Especially in this case, specificity is a heuristic that fails so often that many authors have decided the benefit they get from selectors is not worth the specificity mess and prefer to ditch selectors altogether to avoid it and just use classes + JS for the querying logic.

GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1170#issuecomment-329869487 using your GitHub account
Received on Friday, 15 September 2017 18:52:09 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:18 UTC