意見徵求：匯入 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，如果我們沒有做出您會做的決定，請耐心等待我們。