Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicitly add a breaking change exemption for invalid CSS output #2225

Merged
merged 1 commit into from Apr 23, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 13 additions & 0 deletions README.md
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