Dart Sass (the primary Sass implementation) has deprecated 'mixed declarations' since version 1.77.7, released 9th July 2024.
They've done this so that Sass's implementation of selector nesting is closer aligned with the CSS specification for selector nesting.
Technical explainer of the difference
Consider this piece of Sass code:
```scss
.tardis {
box-sizing: bigger-on-the-inside;
.console-room {
color: white;
}
color: blue;
}
```
Historically, Sass would internally 'hoist' all declarations within a selector to the top level, producing compiled CSS that looked like this:
```css
.tardis {
box-sizing: bigger-on-the-inside;
color: blue;
}
.tardis .console-room {
color: white;
}
```
Although the native CSS nesting specification [originally mimicked this behaviour](https://web.archive.org/web/20240111175511/https://drafts.csswg.org/css-nesting-1/#mixing), [it has since changed](https://drafts.csswg.org/css-nesting-1/#mixing) so that declarations are **not** hoisted and are implicitly treated as separate selectors instead.
My understanding is that this change was made to ensure that CSS can be consistently parsed in the authored order, rather than having elements of the cascade being silently altered in the background.
If/when Sass does the same, it will result in compiled CSS that looks like this:
```css
.tardis {
box-sizing: bigger-on-the-inside;
}
.tardis .console-room {
color: white;
}
.tardis {
color: blue;
}
```
Although this doesn't have immediate ramifications to the cascade or end appearance of a page (potential `@at-root` schenanigans notwithstanding), this does mean that our compiled CSS has the potential to contain many more duplicate selectors in the next major Sass version.
Consequences
Currently, the only side effect of this change is a large number of deprecation warnings being produced when govuk-frontend is used with a recent version of Sass.
In future, when Sass 2.x has been released, it will likely lead to undesirable changes to how our Sass code is being compiled, with many more duplicated selectors and a slight possibility for the style cascade to have been altered.
When the change lands in Sass 2.x it is unlikely (though not infeasible) that any of our styles will break, although there may be an increase in the file size of compiled CSS.
Effort to pay down
Medium
Reason (effort to pay down)
A large number of the warnings come from the third-party sass-mq library, which appears to be unmaintained and unlikely to receive updates to resolve this problem.
It has been suggested that we can likely remove this dependency, as we primarily used it for ease of supporting legacy Internet Explorer versions which we stopped supporting with GOV.UK Frontend v5.
Cause
Dart Sass (the primary Sass implementation) has deprecated 'mixed declarations' since version 1.77.7, released 9th July 2024.
They've done this so that Sass's implementation of selector nesting is closer aligned with the CSS specification for selector nesting.
Technical explainer of the difference
Consider this piece of Sass code: ```scss .tardis { box-sizing: bigger-on-the-inside; .console-room { color: white; } color: blue; } ``` Historically, Sass would internally 'hoist' all declarations within a selector to the top level, producing compiled CSS that looked like this: ```css .tardis { box-sizing: bigger-on-the-inside; color: blue; } .tardis .console-room { color: white; } ``` Although the native CSS nesting specification [originally mimicked this behaviour](https://web.archive.org/web/20240111175511/https://drafts.csswg.org/css-nesting-1/#mixing), [it has since changed](https://drafts.csswg.org/css-nesting-1/#mixing) so that declarations are **not** hoisted and are implicitly treated as separate selectors instead. My understanding is that this change was made to ensure that CSS can be consistently parsed in the authored order, rather than having elements of the cascade being silently altered in the background. If/when Sass does the same, it will result in compiled CSS that looks like this: ```css .tardis { box-sizing: bigger-on-the-inside; } .tardis .console-room { color: white; } .tardis { color: blue; } ``` Although this doesn't have immediate ramifications to the cascade or end appearance of a page (potential `@at-root` schenanigans notwithstanding), this does mean that our compiled CSS has the potential to contain many more duplicate selectors in the next major Sass version.Consequences
Currently, the only side effect of this change is a large number of deprecation warnings being produced when govuk-frontend is used with a recent version of Sass.
In future, when Sass 2.x has been released, it will likely lead to undesirable changes to how our Sass code is being compiled, with many more duplicated selectors and a slight possibility for the style cascade to have been altered.
Impact of debt
Low
Reason (impact of debt)
The warnings are annoying, but they can be silenced.
When the change lands in Sass 2.x it is unlikely (though not infeasible) that any of our styles will break, although there may be an increase in the file size of compiled CSS.
Effort to pay down
Medium
Reason (effort to pay down)
A large number of the warnings come from the third-party
sass-mq
library, which appears to be unmaintained and unlikely to receive updates to resolve this problem.It has been suggested that we can likely remove this dependency, as we primarily used it for ease of supporting legacy Internet Explorer versions which we stopped supporting with GOV.UK Frontend v5.
Overall rating
Low
Reason (overall rating)
No response