征求意见：导入 CSS 文件

随着 Dart Sass 在可用性方面赶上 Ruby Sass，我们开始着手添加新的语言特性。我们正在考虑的第一个特性是用户长期以来一直要求的：添加对导入普通 CSS 文件的支持，而无需将其重命名为 .scss。我们不仅预计这将非常有用，而且它已经在 LibSass 中部分实现，因此这将有助于使实现更一致。

我们还在尝试使用此功能的新流程。为了帮助保持不同实现的行为同步，我们在开始编写代码之前先从该特性的散文规范开始。我们也借此机会征求您，Sass 社区的反馈！在我们有机会根据反馈修改它时，我们希望听到您对新功能的看法。

背景背景永久链接

从历史上看，Sass 的参考实现——首先是 Ruby Sass，然后是 Dart Sass——仅支持导入其他 Sass 文件。但是，LibSass 也支持导入 CSS 文件，并将它们解释为 SCSS。尽管这在技术上违反了实现指南中关于单方面扩展语言的禁止规定，但这些 CSS 导入非常有用，并在 Node.js 社区中被广泛采用。

这一点在语言团队敦促 LibSass 为 CSS 导入添加弃用警告并且用户没有合适的替代方案时变得尤其明显。语言团队聚在一起讨论这个问题，并决定转向允许 CSS 导入，但禁止在导入的文件中使用非 CSS 功能。该提案描述了该 想法的细节。

在撰写本文时，LibSass 的行为是按与具有 .scss 和 .sass 扩展名的文件相同的优先级级别导入具有 .css 扩展名的文件，如果导入在 .css 文件和 .scss 或 .sass 文件之间存在歧义，则会抛出错误。

摘要摘要永久链接

该提案旨在平衡保持与 LibSass 的现有行为的兼容性和转向更符合原则的加载 CSS 方案。这一点尤其重要，因为我们打算允许 @use 加载没有 Sass 功能的 CSS 文件，因此我们希望现有的 CSS 加载支持尽可能相似。

在提案中，查找要导入的 CSS 文件的工作方式与 LibSass 当前的工作方式类似：相对 .css 文件优先于加载路径上任何扩展名的文件，加载路径上较早的 .css 文件优先于加载路径上任何扩展名的文件，foo.css 优先于 index/foo.scss。

加载方案的唯一区别发生在导入在同一路径上的 .css 文件和 .scss 或 .sass 文件之间存在歧义时。LibSass 目前在此处产生错误，但为了最大程度地与现有的 Dart Sass（和 Ruby Sass）行为兼容，该提案使 .scss 或 .sass 文件具有优先级。这不是对 LibSass 行为的重大更改，因为它仅适用于以前会产生 错误的情况。

但是，该提案在解析导入的 CSS 文件方面与 LibSass 大不相同：它禁止在解析的文件中使用所有 SCSS 功能。大多数 SCSS 功能会产生错误（而不是编译为可能无效的普通 CSS），以帮助意外在其 CSS 中编写了 SCSS 的用户了解问题所在。但是，诸如 @import 之类与普通 CSS 重叠的功能将继续呈现为 CSS。

为了避免 LibSass 中突然出现向后不兼容的更改，这也包括对一组弃用警告的提案，这些警告可以添加到 LibSass 的现有行为中，以引导用户避免在导入的 CSS 中使用 Sass 功能，而不会完全破坏其构建 过程。

提供反馈提供反馈永久链接

如果您想详细了解建议的行为将如何工作，请转到 sass/language 存储库并阅读完整提案。您可以跳过“背景”和“摘要”部分，因为它们已包含在上面。但请注意，它是作为规范编写的；它非常适合弄清楚边缘情况的确切工作方式，但它不像上面引用的部分那样具有对话性。

如果您对所写提案有任何问题，或者它没有涵盖对您很重要的用例，请在 sass/language 问题跟踪器中提出。在我们标记提案为“已接受”并进入实施 阶段之前，我们将至少开放两周供讨论。

但是，请注意，虽然我们欢迎社区反馈，但 Sass 的设计最终掌握在语言团队手中。我们绝对会考虑那些发声的用户及其观点和用例，但我们也有责任考虑所有 Sass 新手甚至 CSS 新手，他们还不知道阅读博客或在问题跟踪器中发表评论。请记住，我们谨慎的决策使 Sass 成为今天的样子，如果您对我们没有做出您认为会做出的决定，请耐心等待！