• Proposal ([Bogus Combinators] Create a proposal #3342)

Deprecation

• Tests (Add tests for bogus combinators sass-spec#1803)
• Dart Sass (Deprecate bogus combinators dart-sass#1740)
• Documentation (Document the bogus combinator breaking change sass-site#654)
• Update canonical spec ([Bogus Combinators] Update the specification #3362)

Removal

• Tests
• Dart Sass
• Documentation

Currently, Sass is very liberal when it comes to where explicit selector combinators can be written—much more so than CSS itself. We allow:

• Multiple combinators between compound selectors (a > + b).
• Combinators at the beginning of selectors (> a).
• Combinators at the end of selectors (a >).

The latter two are useful when nesting style rules, but the former has no known use at all. Historically, we've said that we support these because they enable some browser hacks, but this seems to be purely hypothetical: browserhacks.com is the most comprehensive source of hacks I've found, and it doesn't list any hacks that are enabled by this support, even among its "legacy hacks".

In addition, supporting these selectors imposes substantial complexity on Sass implementations. They cause bugs (sass/dart-sass#1053) and make the data model more complex than it needs to be. This in turn makes bugs like #1807 that don't involve non-standard combinators more difficult to resolve.

Fortunately, these bogus combinators are unlikely to be widely-used in practice and have no effect in real-world browsers, which gives us considerable freedom to drop support for them without needing to do a lengthy deprecation period. We'll need to be careful to preserve the useful aspects of their behavior, and we'll probably want to make these produce errors eventually, but for the time being we can just cause them to omit selectors. In particular:

• If any of a style rule's selectors contains a leading, trailing, or multiple combinator after nesting is resolved, omit that style rule from the generated CSS and emit a deprecation warning.

• If a selector with a leading or trailing combinator is used with any extend-related infrastructure, emit a deprecation warning but proceed as usual for now. Although this isn't really desirable, it can produce valid CSS, as in selector.extend(".a .b", ".a", ".x >").

• If a selector with a doubled combinator is used with any extend-related infrastructure, emit a deprecation warning and treat that selector as though it matches no elements (which is in fact the case).

Then, when we release the next major version of Dart Sass, we can start producing errors for the situations we had previously been producing deprecation warnings.