Request For Comments: Importieren von CSS Dateien

Da Dart Sass in Bezug auf die Benutzerfreundlichkeit mit Ruby Sass gleichzieht, beginnen wir mit der Arbeit an neuen Funktionen für die Sprache. Die erste Funktion, die wir uns ansehen, ist eine, die von Benutzern seit langem gewünscht wird: die Unterstützung für das Importieren von reinen CSS-Dateien, ohne sie in .scss umbenennen zu müssen. Wir erwarten nicht nur, dass dies sehr nützlich sein wird, sondern es ist bereits teilweise in LibSass implementiert, so dass dies dazu beitragen wird, die Implementierungen besser aufeinander abzustimmen .

Wir probieren mit dieser Funktion auch einen neuen Prozess aus. Um das Verhalten verschiedener Implementierungen synchron zu halten, beginnen wir mit einer Prosa-Spezifikation der Funktion, bevor wir mit dem Schreiben von Code fortfahren. Wir nutzen dies auch als Gelegenheit, Feedback von Ihnen, der Sass-Community, einzuholen! Wir möchten Ihre Gedanken zu der neuen Funktion hören, während wir die Möglichkeit haben, sie auf Basis dieses Feedbacks zu überarbeiten.

HintergrundHintergrund-Permalink

Historisch gesehen unterstützten die Referenzimplementierungen von Sass – zuerst Ruby Sass, dann Dart Sass – nur den Import anderer Sass-Dateien. LibSass unterstützte jedoch auch den Import von CSS-Dateien und interpretierte sie so, als wären sie SCSS. Obwohl dies technisch gegen das Verbot des Implementierungsleitfadens verstieß, die Sprache einseitig zu erweitern, waren diese CSS-Importe nützlich und wurden in der Node.js- Community weit verbreitet.

Dies wurde besonders deutlich, als LibSass auf Drängen des Sprachteams Deprecation-Warnungen für CSS-Importe hinzufügte und die Benutzer ohne geeigneten Ersatz dastanden. Das Sprachteam kam zusammen, um das Problem zu diskutieren, und beschloss, CSS-Importe zuzulassen, aber die Verwendung von Nicht-CSS-Funktionen in den importierten Dateien zu verbieten. Der Vorschlag beschreibt die Einzelheiten dieser Idee.

Das Verhalten von LibSass zum Zeitpunkt der Erstellung ist, Dateien mit der Erweiterung .css auf derselben Prioritätsstufe wie Dateien mit den Erweiterungen .scss und .sass zu importieren und einen Fehler auszugeben, wenn ein Import zwischen einer .css-Datei und einer .scss- oder .sass-Datei mehrdeutig ist.

ZusammenfassungZusammenfassungs-Permalink

Der Vorschlag zielt darauf ab, ein Gleichgewicht zwischen der Wahrung der Kompatibilität mit dem bestehenden Verhalten von LibSass und der Hinwendung zu einem prinzipielleren Schema für das Laden von CSS zu finden. Dies ist besonders wichtig, da wir beabsichtigen, @use zu erlauben, um CSS-Dateien ohne Sass-Funktionen zu laden, daher wollen wir, dass die bestehende CSS-Ladeunterstützung so ähnlich wie möglich ist.

Das Auffinden von CSS-Dateien für den Import funktioniert unter dem Vorschlag ähnlich wie derzeit in LibSass: Eine relative .css-Datei hat Vorrang vor Dateien mit beliebiger Erweiterung im Load Path, eine .css-Datei früher im Load Path hat Vorrang vor einer Datei mit beliebiger Erweiterung später im Load Path, und foo.css hat Vorrang vor index/foo.scss.

Der einzige Unterschied im Ladeschema tritt auf, wenn ein Import zwischen einer .css-Datei und einer .scss- oder .sass-Datei am selben Pfad mehrdeutig ist. LibSass erzeugt hier derzeit einen Fehler, aber um die Kompatibilität mit dem bestehenden Dart Sass (und Ruby Sass) Verhalten zu maximieren, hat der Vorschlag, dass die .scss- oder .sass-Datei Vorrang hat. Dies ist keine abwärtskompatible Änderung des LibSass-Verhaltens, da sie nur in Situationen gilt, die zuvor einen Fehler verursacht hätten.

Der Vorschlag weicht jedoch erheblich von LibSass bei der Analyse der importierten CSS-Dateien ab: Er verbietet jegliche Verwendung von SCSS-Funktionen in den analysierten Dateien. Die meisten SCSS-Funktionen erzeugen Fehler (anstatt zu reinem, wahrscheinlich ungültigem CSS zu kompilieren), um Benutzern zu helfen, die versehentlich SCSS in ihrem CSS geschrieben haben, zu erkennen, was schiefgeht. Funktionen wie @import, die mit reinem CSS überlappen, werden jedoch weiterhin als CSS gerendert.

Um eine plötzliche abwärtskompatible Änderung in LibSass zu vermeiden, beinhaltet dies auch einen Vorschlag für eine Reihe von Deprecation-Warnungen, die dem bestehenden Verhalten von LibSass hinzugefügt werden können, um Benutzer davon abzuhalten, Sass-Funktionen in ihrem importierten CSS zu verwenden, ohne ihren Build- Prozess vollständig zu unterbrechen.

Feedback gebenFeedback geben-Permalink

Wenn Sie mehr Details darüber wünschen, wie genau das vorgeschlagene Verhalten funktionieren wird, gehen Sie zum sass/language Repository und lesen Sie den vollständigen Vorschlag. Sie können die Abschnitte Hintergrund und Zusammenfassung überspringen, da sie oben enthalten sind. Beachten Sie jedoch, dass er als Spezifikation geschrieben ist; er ist großartig, um herauszufinden, wie genau ein Randfall funktionieren sollte, aber er ist nicht so gesprächig wie die oben zitierten Abschnitte.

Wenn Sie Probleme mit dem vorgeschlagenen Verhalten haben oder wenn es einen für Sie wichtigen Anwendungsfall nicht abdeckt, bringen Sie dies bitte im sass/language Issue Tracker zur Sprache. Wir werden ihn mindestens zwei Wochen lang zur Diskussion offen halten, bevor wir den Vorschlag als "akzeptiert" markieren und zur Implementierungs- Phase übergehen.

Bitte beachten Sie jedoch, dass das Design von Sass letztendlich in den Händen des Sprachteams liegt, auch wenn wir Community-Feedback begrüßen. Wir werden die Perspektiven und Anwendungsfälle von Benutzern, die sich äußern, unbedingt berücksichtigen, aber es ist auch unsere Aufgabe, all die Benutzer zu berücksichtigen, die neu bei Sass oder sogar bei CSS sind und die noch nicht wissen, dass sie Blogs lesen oder auf Issue Tracker kommentieren sollten. Denken Sie daran, dass unsere sorgfältige Entscheidungsfindung Sass zu dem gemacht hat, was es heute ist, und haben Sie Geduld mit uns, wenn wir nicht die Entscheidungen treffen, die Sie treffen würden!