From eafc279ae77382314ff2fd0e005263d50eccfa7c Mon Sep 17 00:00:00 2001 From: Natalie Weizenbaum Date: Tue, 23 Apr 2024 16:23:33 -0700 Subject: [PATCH] Explicitly add a breaking change exemption for invalid CSS output (#2225) This was always implicitly the case (as pointed out in the new section), but this makes it explicit. --- README.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/README.md b/README.md index 844cdf0fc..fbc545065 100644 --- a/README.md +++ b/README.md @@ -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) @@ -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