コメント募集: CSS ファイルのインポート

Dart Sassの使いやすさがRuby Sassに追いついてきたので、言語に新しい機能を追加する作業を開始します。最初に検討している機能は、ユーザーから長く要望されてきたもので、拡張子を.scssに変更することなく、プレーンなCSSファイルをインポートするサポートを追加することです。これは非常に役立つと期待されるだけでなく、LibSassではすでに部分的に実装されているため、実装をより一致させるのに役立ちます。

また、この機能では新しいプロセスを試しています。異なる実装の動作を同期させるために、コードの記述に進む前に、機能の文章による仕様から始めています。また、Sassコミュニティの皆さんからのフィードバックを求める機会とも考えています。この新しい機能について、フィードバックに基づいて修正する機会があるうちに、皆さんの考えを聞きたいのです。

背景背景へのパーマリンク

歴史的に、Sassの参照実装（最初はRuby Sass、次にDart Sass）は、他のSassファイルのインポートのみをサポートしていました。しかし、LibSassはCSSファイルのインポートもサポートしており、SCSSとして解釈していました。これは技術的には実装ガイドの言語を一方的に拡張することを禁止する規定に違反していましたが、これらのCSSインポートは有用であり、Node.js コミュニティで広く採用されていました。

言語チームの勧めでLibSassがCSSインポートの非推奨警告を追加し、ユーザーが適切な代替手段なしに取り残されたとき、これが特に明らかになりました。言語チームはこの問題を議論するために集まり、CSSインポートを許可するが、インポートされたファイルでCSS以外の機能を使用することを禁止する方向へ進むことを決定しました。この提案では、そのアイデアの詳細について説明します。

執筆時点でのLibSassの動作は、拡張子.cssのファイルを、.scssおよび.sass拡張子のファイルと同じ優先度レベルでインポートし、.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を記述してしまったユーザーが何が間違っているのかを認識できるようにします。ただし、プレーンなCSSと重複する@importのような機能は、引き続きCSSとしてレンダリングされます。

LibSassで突然後方互換性のない変更を避けるために、これには、LibSassの既存の動作に追加できる一連の非推奨警告の提案も含まれており、ビルド プロセスを完全に中断することなく、インポートされたCSSでSass機能を使用することを避けるようにユーザーを誘導できます。

フィードバックの提供フィードバック提供へのパーマリンク

提案された動作がどのように機能するかの詳細を知りたい場合は、sass/languageリポジトリに移動して、提案全体をお読みください。上記の背景と概要のセクションは含まれているため、スキップできます。ただし、仕様として書かれていることに注意してください。エッジケースが正確にどのように機能する必要があるかを把握するのに最適ですが、上記の引用セクションほど会話的ではありません。

記述された提案に問題がある場合、または提案が自分にとって重要なユースケースをカバーしていない場合は、sass/languageの課題追跡ツールで指摘してください。提案を「承認済み」とマークして実装 フェーズに進む前に、少なくとも2週間は議論のために公開しておきます。

ただし、コミュニティからのフィードバックを歓迎しますが、Sassの設計は最終的には言語チームの手に委ねられていることに注意してください。声を上げたユーザーの視点やユースケースは絶対考慮しますが、SassやCSSを初めて使用し、ブログを読んだり課題追跡ツールにコメントしたりする方法をまだ知らないすべてのユーザーを考慮することも私たちの仕事です。慎重な意思決定が今日のSassを作り上げたことを忘れず、私たちがあなたが望む決定をしなかったとしても、私たちに辛抱強く接してください！