This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"3.6 Satisfying Matching Criteria" Specifically we have a user with this scenario: my-figure shadow-root: <content select="span:not(.caption)"></content> Figure 7: <content select="span.caption"></content> where his input looks something like this: <my-figure> <span>Hello World!</span> <span class="caption">The caption</span> <my-figure> Without :not() he is forced to: (1) rearrange his input content, (2) rearrange nodes imperatively, or (3) use CSS to order nodes different at render-time, all of which are invasive solutions. I recognize the slippery slope of adding additional abilities to insertion selectors, but my (admittedly naive) reading of the SELECTORS spec seemed to imply that supporting :not() may not violate the performance constraints.
These were removed as part of work on bug 21924. We really need to add back at least some of these. For example :nth-type and friends is necessary to rationalize implementing <details> and <fieldset> using Shadow DOM. The spec still uses them, even: http://w3c.github.io/webcomponents/spec/shadow/#html-elements-and-their-shadow-trees
We should definitely add back :not(). My criteria for what goes and what stays is that we should only have selectors which depend on internal state of an element. That makes figuring out dependencies much more sane. :not() fits that criteria. We can certainly discuss having things like :nth-of-type etc. But lets do that as a separate bug, based on use cases and while documenting dependencies.
(In reply to Jonas Sicking from comment #2) > We can certainly discuss having things like :nth-of-type etc. But lets do > that as a separate bug, based on use cases and while documenting > dependencies. Sounds good. Filed bug 24872 for that.
Let me add ':not' back to the spec.
':not()' came back to the spec at https://github.com/w3c/webcomponents/commit/563119439b1fcdddc1041abef1bc764e5e048d98