[FR] Explode/expand wrapped selectors (:not)

[mgreter]

LibSass will merge a change that fixes the most urgent issues with handling :not wrapped selectors. Unfortunately I'm not able to avoid a breaking* change. For illustration see the following sample:

:not(.asd, .qwe) {
  content: test;
}
:not(.foo) {
  content: test;
}
.bar, .baz {
  @extend .foo;
}

Compile to (with ruby sass):

:not(.asd, .qwe) {
  content: list; }
:not(.foo):not(.bar):not(.baz) {
  content: test; }

With libsass this will yield:

:not(.asd):not(.qwe) {
  content: list; }
:not(.foo):not(.bar):not(.baz) {
  content: test; }

The only difference is that :not(.asd, .qwe) is expanded to :not(.asd):not(.qwe). My argument to merge this breaking* change in libsass is simply that this is invalid css anyway.

The negation CSS pseudo-class, :not(X), is a functional notation taking a simple selector X as an argument. It matches an element that is not represented by the argument. X must not contain another negation selector.

Therefore I would like to ask if ruby sass would be willing to adopt this behavior?
IMO it makes specially sense if you look at what happens with the @extend above.

[chriseppstein]

This seems reasonable to me. The syntax we're generating is legal in selectors level 4, but not in level 3 and does not currently work for chrome.

[chriseppstein]

@nex3 thoughts?

[nex3]

This is intended behavior. The :not(.asd, .qwe) selector is what the user originally authored; Sass won't create new Selectors 3-incompatible code if it can help it, but we also won't stop the user from doing so.

In general, we don't do any modificiation of user-authored selectors beyond what's necessary to resolve @extend. Doing it in this particular instance would be a special case that would muddy the waters about how much users can expect Sass to fix up their limited-compatibility pure CSS.