ampersands in :not selector

[blimmer]

In the process of upgrading to libsass 3.3.x, I noticed that a (potentially incorrect) selector I was using before was no longer working.

Sass in question

.header {
  .nav-text-link:not(&.popover-link) {
    margin: 10px;
  }
}

Libsass 3.3.2 (invalid css)

.header .nav-text-link:not(&.popover-link) {
  margin: 10px; }

Libsass 3.2.5

.header .nav-text-link:not(.popover-link) {
  margin: 10px;
}

However, I realized that my use of the ampersand character in that :not selector was actually incorrect from the beginning. What I wanted was really:

.header {
  .nav-text-link:not(.popover-link) {
    margin: 10px;
  }
}

Ruby 3.4.14

Out of curiosity I ran the original sass (with the ampersand) against Ruby 3.4.14 and got this output:

.nav-text-link:not(.header.popover-link) {
  margin: 10px;
}

So there's definitely (at least) a bug with libsass leaving an ampersand in compiled css. Then there's the issue of what the "correct" interpretation of a nested ampersand in a :not selector is.

[mgreter]

Thanks for the report. Handling of the :not pseudo selector is somewhat special and incomplete in libsass, as the following samples illustrate (I know we also need to add some implementation somewhere in and around unify_with). Basically we don't eval stuff inside wrapped selectors. Once you add an interpolation to a selector, we will evaluate and re-parse it (which btw. gives me a headache for source-maps), so in this case the parent selector will actually be resolved (see second sample).

foo#{b+ar} {
  :not(&#{'.bar'}) {
    color: #{baz};
  }
}

So this will actually work somewhat (libsass keeps the .header selector):

.header {
  .nav-text-link:not(#{&}.popover-link) {
    margin: 10px;
  }
}

I could probably patch just that issue by explicitly parentize wrapped selectors in the eval stage. But I really would like to understand why :not does what it does.

Some excerpt from current w3c specs: "The negation pseudo-class, :not(X), is a functional notation taking a simple selector (excluding the negation pseudo-class itself) as an argument. It represents an element that is not represented by its argument. Negations may not be nested; :not(:not(...)) is invalid. Note also that since pseudo-elements are not simple selectors, they are not a valid argument to :not()." ... "A simple selector is either a type selector, universal selector, attribute selector, class selector, ID selector, or pseudo-class"

Basically what ruby sass produces is invalid css and browsers should ignore it (Firefox emits this warning for me, sorry it's german: "Abschließende ')' fehlt in Negations-Pseudoklasse '['. Regelsatz wegen ungültigem Selektor ignoriert.")

So the question is why you really want to use something like this in the first place.

//CC @chriseppstein what is the stand here for ruby? IMO the only way to get a valid selector is when we only have one parent selector (also attribute selector will not work) that merges into another typeselector, as with foo { :not(&bar) ... }, which should in my intuition result in foo :not(foobar) ..., but will currently yield :not(foobar) ... in ruby sass!? Btw. AFAIK we have similar issues with :has "pseudo selector".

[mgreter]

Fixes on latest master and will be in 3.3.3.