Unclear default behavior for Sass parent selectors

[ByteB4rb1e]

Hi.

.name- {
    &suffix {
        content: '';
    }
}

triggers rule selector-class-pattern, though this is valid for adding suffixes (https://sass-lang.com/documentation/style-rules/parent-selector/) in Sass.

In my opinion, it is insufficient to rely on a rule for evaluating a selector before it has been resolved in nested SCSS structures, so I would assume it to be a default not to have such a rule for Sass SCSS evaluation? I advocate for using well-known rule sets, instead of custom adaptions, that's why I'm bringing this up.

Is anybody able to clarify this for me?

Kind regards

Tiara

[kristerkari]

Thanks @ByteB4rb1e !

I'm not sure if the selector-class-pattern rule works for all different kinds of Sass related selectors, but at least for your specific problem the selector could be written in a different way to make the linting pass:

.name {
  &-suffix {
    content: '';
  }
}

We could consider disabling that specific rule if it seems to cause problems, but at least for your problem there seems to be an easy workaround.

[ByteB4rb1e]

@kristerkari, thank you for your response!

I've resorted to disabling the rule altogether after an attempt of rewriting it, but it didn't seem feasible to solve this purely through regular expressions.

Before I continue, I don't really have an objective with this issue report, I'm just trying to build a case for a well-reasoned exemption of this rule (in special cases), in addition to getting a better understanding, so that I might be able to propose meaningful enhancements.

Here's a specific case, in which I think a deviation is well-reasoned:

https://github.com/ByteB4rb1e/html-theme-ref/blob/f1ac67afc430ab3f54d4bc8c145c7337c59583a9/src/style/vendors/Boxicons/_main.scss#L271-L420

It feels unintuitive to apply a hyphen to all inner selector.

I'm not trying to make a tabs vs. spaces kind of argument, because inherently the discussion could be seen as: Is a suffix being applied to the inner's parent selector, or a prefix being applied to the outer selector? I'm just trying to reason that depending on the standpoint of what someone considers the linter actually evaluating, the rule can be seen as either right or wrong.

In natural language, the hyphen indicates the suffix, hence your workaround would be well reasoned for that case.

My reasoning is that the linting is against the source code, not the intended CSS stylesheet serialization. E.g.. looking at the Dart Sass sources and how the abstract syntax tree (AST) is build before serialization, it is much rather that a prefix (outer selector) is being applied to the inner selector. While the linter treats the inner selector as receiving a suffix, the actual AST resolution applies the prefix first.

Hence, the rule currently enforces constraints at a stage before full resolution, not accounting for how the AST actually processes nested structures. Since the inner selector is a node in its own right, the composition logic should prioritize the correct hierarchical flow rather than enforcing static suffix-based validation.

I don't know the roadmap of stylelint-scss, but would it be of help, if I researched other Sass implementations in addition to Dart Sass and how they serialize the AST? Maybe this could be some input for considerations of future enhancements?

[kristerkari]

It feels unintuitive to apply a hyphen to all inner selector.

I'm not trying to make a tabs vs. spaces kind of argument, because inherently the discussion could be seen as: Is a suffix being applied to the inner's parent selector, or a prefix being applied to the outer selector? I'm just trying to reason that depending on the standpoint of what someone considers the linter actually evaluating, the rule can be seen as either right or wrong.

I don't disagree with this reasoning, but the challenge for me is that I have no idea what feels logical or natural for the majority of the users of this config.

One possible solution would be to still have the selector-class-pattern rule enabled, but modify the regex a bit to allow the trailing hyphen in classes.

That way both styles would be supported.