Skip to content

Commit

Permalink
Explicitly add a breaking change exemption for invalid CSS output (#2225
Browse files Browse the repository at this point in the history
)

This was always implicitly the case (as pointed out in the new
section), but this makes it explicit.
  • Loading branch information
nex3 authored Apr 23, 2024
1 parent b97f26f commit eafc279
Showing 1 changed file with 13 additions and 0 deletions.
13 changes: 13 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,7 @@ A [Dart][dart] implementation of [Sass][sass]. **Sass makes CSS fun**.
* [Compatibility Policy](#compatibility-policy)
* [Browser Compatibility](#browser-compatibility)
* [Node.js Compatibility](#nodejs-compatibility)
* [Invalid CSS](#invalid-css)
* [Embedded Dart Sass](#embedded-dart-sass)
* [Usage](#usage)
* [Behavioral Differences from Ruby Sass](#behavioral-differences-from-ruby-sass)
Expand Down Expand Up @@ -405,6 +406,18 @@ considers itself free to break support if necessary.

[the Node.js release page]: https://nodejs.org/en/about/previous-releases

### Invalid CSS

Changes to the behavior of Sass stylesheets that produce invalid CSS output are
_not_ considered breaking changes. Such changes are almost always necessary when
adding support for new CSS features, and delaying all such features until a new
major version would be unduly burdensome for most users.

For example, when Sass began parsing `calc()` expressions, the invalid
expression `calc(1 +)` became a Sass error where before it was passed through
as-is. This was not considered a breaking change, because `calc(1 +)` was never
valid CSS to begin with.

## Embedded Dart Sass

Dart Sass includes an implementation of the compiler side of the [Embedded Sass
Expand Down

0 comments on commit eafc279

Please sign in to comment.