Deep @extend specificity problems

[mgol]

The following SCSS input:

%a {
    &::-webkit-scrollbar {
        color: green;
    }
}
%b {
    @extend %a;
}

.a {
    .b {
        @extend %a;
    }

    .c {
        .b {
            @extend %b;
        }
    }
}

is compiled via Ruby Sass (3.4.5) to:

.a .c .b::-webkit-scrollbar, .a .b::-webkit-scrollbar {
  color: green; }

and via libsass (using node-sass 1.1.4) to:

.a .b::-webkit-scrollbar {
  color: green; }

[mgol]

BTW, what's interesting here is that if I just change ::-webkit-scrollbar in the source to, e.g., .d, Ruby Sass gives me:

.a .d.b {
  color: green; }

i.e. the same what libsass does. Weird.

EDIT: I submitted an issue to Ruby Sass about that: sass/sass#1495

[mgol]

I'll wait with submitting a PR to sass-spec until the Ruby Sass issue clarifies on what should really be happening.

[mgol]

As Sass maintainer indicated in sass/sass#1495 (comment), Sass is correct here due to pseudo-element low specificity. This is confirmed to be a libsass bug then.

I'll submit a spec.

[mgol]

Spec submitted: sass/sass-spec#115

[mgol]

This, BTW, is more serious than my other recent issues as it can change semantics in some cases. I wonder if a similar spec but with a class instead of a pseudo-selector shouldn't be added to show the difference between those two that libsass doesn't currently respect?

This is AFAIK one of the three issues that currently prevent our quite a large Sass code base from migrating to libsass (other two being @supports and @at-root support). The rest is mostly stylistic changes - a little annoying but nothing blocking.

Great job!

[mgreter]

This is directly related to #823

[xzyfer]

Looks like this made it into 3.2.0. Updated the milestone.