invalid order of pseudo-selectors

[FND]

Using v1.14.0, the following code:

%highlight {
    &:before {
        color: red;
    }
}

article:empty {
    @extend %highlight;
}

results in

article:before:empty {
  color: red;
}

(only when using @extend though; when embedding the nested &:before rule set, the order of pseudo-selectors is reversed)

This order of pseudo-selectors :before:empty appears to be invalid, as both Firefox (v62.0.2) and Chrome (v69.0.3497.100) simply ignore the entire rule set (even if it's a list of multiple selectors, those are ignored as well) - reversing the order to :empty:before makes everything work as expected: test case

[nex3]

The single-colon syntax for :before is deprecated, specifically because it's semantically a pseudo-element but that syntax makes it look like a pseudo-class. If you write it ::before, this will work; Sass knows to put pseudo-elements at the end of selectors, but it treats all pseudo-classes as equivalent.

[FND]

Thanks @nex3, that did indeed fix it!

In a way, I'm glad to finally have a concrete reason to use ::. Having said that, given the pervasive use of single colons (I'm guessing many people are unaware of the distinction), this behavior seems like a hazardous trap: It took me several hours to debug this issue - indeed, recognizing the order of pseudo-selectors as a potential culprit was a lucky accident. (So much so that for a while I'd lost trust in the @extend mechanism's reliability.)

So while I appreciate dart-sass being strict about this, emitting a warning might save some users a lot of trouble down the road - especially given browsers' (surprising) behavior of ignoring subsequent selectors.

[nex3]

Fair enough, I suppose it's not too hard to special-case :before, :after, :first-line, and :first-letter.

[FND]

Great, I appreciate that!