Currently, our lint definition enforces @include functions being at the beginning of a style block. This was a fine rule to settle on, because Sass would always output nested blocks after non-nested properties.
So given this code:
@mixin vertical-rhythm($space: 1lh) {
> * + * {
margin-block-start: $space;
}
}
.example {
@include vertical-rhythm;
color: red;
}
The output would be:
.example {
color: red;
}
.example > * + * {
margin-block-start: 1lh;
}
But Sass has announced they'll be changing this behavior in a future update. At some point, nested blocks will respect the output order: https://sass-lang.com/documentation/breaking-changes/mixed-decls/
With that change, the order of the output will be reversed:
.example > * + * {
margin-block-start: 1lh;
}
.example {
color: red;
}
Because of that, I think we should consider either:
- Enforcing
@include statements and nesting to come after top-level declarations. This would enforce current behavior.
- Remove any
@include order enforcement at all, allowing authors to leverage order as they see fit.
Currently, our lint definition enforces
@includefunctions being at the beginning of a style block. This was a fine rule to settle on, because Sass would always output nested blocks after non-nested properties.So given this code:
The output would be:
But Sass has announced they'll be changing this behavior in a future update. At some point, nested blocks will respect the output order: https://sass-lang.com/documentation/breaking-changes/mixed-decls/
With that change, the order of the output will be reversed:
Because of that, I think we should consider either:
@includestatements and nesting to come after top-level declarations. This would enforce current behavior.@includeorder enforcement at all, allowing authors to leverage order as they see fit.