@import
Sass erweitert die CSS @import-Regel um die Möglichkeit, Sass- und CSS-Stylesheets zu importieren. Dies ermöglicht den Zugriff auf Mixins, Funktionen und Variablen und fasst den CSS-Code mehrerer Stylesheets zusammen. Im Gegensatz zu einfachen CSS-Imports, bei denen der Browser mehrere HTTP-Anfragen stellen muss, während er Ihre Seite rendert, werden Sass-Imports vollständig während der Kompilierung verarbeitet.
Sass-Imports haben die gleiche Syntax wie CSS-Imports, mit der Ausnahme, dass mehrere Imports durch Kommas getrennt werden können, anstatt dass jeder eine eigene @import-Anweisung benötigt. Außerdem müssen im eingedrückten Syntax importierte URLs keine Anführungszeichen haben.
⚠️ Vorsicht!
Das Sass-Team rät von der weiteren Verwendung der @import-Regel ab. Sass wird sie in den nächsten Jahren schrittweise auslaufen lassen und schließlich vollständig aus der Sprache entfernen. Bevorzugen Sie stattdessen die @use-Regel. (Beachten Sie, dass nur Dart Sass derzeit @use unterstützt. Benutzer anderer Implementierungen müssen stattdessen die @import-Regel verwenden.)
Was ist falsch an @import?
Die @import-Regel hat eine Reihe ernster Probleme.
-
@importmacht alle Variablen, Mixins und Funktionen global zugänglich. Dies macht es für Personen (oder Werkzeuge) sehr schwierig zu erkennen, wo etwas definiert ist. -
Da alles global ist, müssen Bibliotheken ihren Mitgliedern Präfixe hinzufügen, um Namens kollisionen zu vermeiden.
-
@extend-Regeln sind ebenfalls global, was es schwierig macht vorherzusagen, welche Stilregeln erweitert werden. -
Jedes Stylesheet wird ausgeführt und sein CSS ausgegeben, *jedes Mal*, wenn es
@importiert wird. Dies erhöht die Kompilierungszeit und erzeugt aufgeblähten Output. -
Es gab keine Möglichkeit, private Mitglieder oder Platzhalterselektoren zu definieren, die für nachfolgende Stylesheets unzugänglich waren.
Das neue Modulsystem und die @use-Regel lösen all diese Probleme.
Wie migriere ich?
Wir haben ein Migrationswerkzeug geschrieben, das die meisten auf @import basierenden Codes im Handumdrehen automatisch in auf @use basierenden Code konvertiert. Zeigen Sie ihm einfach Ihre Einstiegspunkte und lassen Sie es laufen!
SCSS-Syntax
// foundation/_code.scss
code {
padding: .25em;
line-height: 0;
}
// foundation/_lists.scss
ul, ol {
text-align: left;
& & {
padding: {
bottom: 0;
left: 0;
}
}
}
// style.scss
@import 'foundation/code', 'foundation/lists';
Sass-Syntax
// foundation/_code.sass
code
padding: .25em
line-height: 0
// foundation/_lists.sass
ul, ol
text-align: left
& &
padding:
bottom: 0
left: 0
// style.sass
@import foundation/code, foundation/lists
CSS-Ausgabe
code {
padding: .25em;
line-height: 0;
}
ul, ol {
text-align: left;
}
ul ul, ol ol {
padding-bottom: 0;
padding-left: 0;
}
Wenn Sass eine Datei importiert, wird diese Datei so ausgewertet, als ob ihr Inhalt direkt anstelle des @import eingefügt worden wäre. Alle Mixins, Funktionen und Variablen aus der importierten Datei werden verfügbar gemacht, und ihr gesamter CSS-Code wird genau an der Stelle eingefügt, an der der @import geschrieben wurde. Darüber hinaus sind alle Mixins, Funktionen oder Variablen, die vor dem @import definiert wurden (auch aus anderen @imports), in dem importierten Stylesheet verfügbar.
⚠️ Vorsicht!
Wenn dasselbe Stylesheet mehr als einmal importiert wird, wird es jedes Mal erneut ausgewertet. Wenn es nur Funktionen und Mixins definiert, ist dies normalerweise kein großes Problem, aber wenn es Stilregeln enthält, werden diese mehr als einmal zu CSS kompiliert.
Datei findenDatei finden Permalink
Es wäre nicht schön, für jedes importierte Stylesheet absolute URLs anzugeben, daher vereinfacht der Algorithmus von Sass zum Auffinden einer zu importierenden Datei die Sache ein wenig. Zunächst müssen Sie die Dateiendung der zu importierenden Datei nicht explizit angeben; @import "variablen" lädt automatisch variablen.scss, variablen.sass oder variablen.css.
⚠️ Vorsicht!
Um sicherzustellen, dass Stylesheets auf jedem Betriebssystem funktionieren, importiert Sass Dateien über die *URL* und nicht über den *Dateipfad*. Das bedeutet, dass Sie Schrägstriche verwenden müssen, keine Backslashes, auch wenn Sie unter Windows arbeiten.
Lade PfadeLade Pfade Permalink
Alle Sass-Implementierungen erlauben es Benutzern, *Lade Pfade* anzugeben: Pfade auf dem Dateisystem, in denen Sass nach Imports sucht. Wenn Sie beispielsweise node_modules/susy/sass als Lade Pfad angeben, können Sie @import "susy" verwenden, um node_modules/susy/sass/susy.scss zu laden.
Imports werden jedoch immer relativ zur aktuellen Datei aufgelöst. Lade Pfade werden nur verwendet, wenn keine relative Datei existiert, die dem Import entspricht. Dies stellt sicher, dass Sie Ihre relativen Imports nicht versehentlich durcheinander bringen, wenn Sie eine neue Bibliothek hinzufügen.
💡 Lustige Tatsache
Im Gegensatz zu einigen anderen Sprachen erfordert Sass nicht, dass Sie ./ für relative Imports verwenden. Relative Imports sind immer verfügbar.
PartialsPartials Permalink
Als Konvention beginnen Sass-Dateien, die nur zum Import bestimmt sind und nicht eigenständig kompiliert werden sollen, mit einem Unterstrich (_, wie in _code.scss). Diese werden als *Partials* bezeichnet und weisen Sass-Werkzeuge an, diese Dateien nicht eigenständig zu kompilieren. Sie können den Unterstrich beim Importieren eines Partials weglassen.
Index-DateienIndex-Dateien Permalink
- Dart Sass
- ✓
- LibSass
- seit 3.6.0
- Ruby Sass
- seit 3.6.0
Wenn Sie eine _index.scss oder _index.sass in einem Ordner erstellen, wird diese Datei geladen, wenn der Ordner selbst importiert wird, anstelle des Inhalts.
SCSS-Syntax
// foundation/_code.scss
code {
padding: .25em;
line-height: 0;
}
// foundation/_lists.scss
ul, ol {
text-align: left;
& & {
padding: {
bottom: 0;
left: 0;
}
}
}
// foundation/_index.scss
@import 'code', 'lists';
// style.scss
@import 'foundation';
Sass-Syntax
// foundation/_code.sass
code
padding: .25em
line-height: 0
// foundation/_lists.sass
ul, ol
text-align: left
& &
padding:
bottom: 0
left: 0
// foundation/_index.sass
@import code, lists
// style.sass
@import foundation
CSS-Ausgabe
code {
padding: .25em;
line-height: 0;
}
ul, ol {
text-align: left;
}
ul ul, ol ol {
padding-bottom: 0;
padding-left: 0;
}
Benutzerdefinierte ImporterBenutzerdefinierte Importer Permalink
Alle Sass-Implementierungen bieten eine Möglichkeit, benutzerdefinierte Importer zu definieren, die steuern, wie @imports Stylesheets finden.
-
Node Sass und Dart Sass auf npm bieten eine
importerOption als Teil ihrer JS API. -
Dart Sass auf pub bietet eine abstrakte
ImporterKlasse, von der ein benutzerdefinierter Importer abgeleitet werden kann. -
Ruby Sass bietet eine abstrakte
Importers::BaseKlasse, von der ein benutzerdefinierter Importer abgeleitet werden kann.
VerschachtelungVerschachtelung Permalink
Imports werden normalerweise auf der obersten Ebene eines Stylesheets geschrieben, müssen es aber nicht sein. Sie können auch innerhalb von Stilregeln oder einfachen CSS-At-Rules verschachtelt werden. Der importierte CSS-Code wird in diesem Kontext verschachtelt, was verschachtelte Imports nützlich macht, um einen Teil von CSS auf ein bestimmtes Element oder eine Media Query zu beschränken. Top-Level-Mixins, Funktionen oder Variablen, die in einem verschachtelten Import definiert werden, sind nur im verschachtelten Kontext verfügbar.
SCSS-Syntax
// _theme.scss
pre, code {
font-family: 'Source Code Pro', Helvetica, Arial;
border-radius: 4px;
}
// style.scss
.theme-sample {
@import "theme";
}
Sass-Syntax
// _theme.sass
pre, code
font-family: 'Source Code Pro', Helvetica, Arial
border-radius: 4px
// style.sass
.theme-sample
@import theme
CSS-Ausgabe
.theme-sample pre, .theme-sample code {
font-family: 'Source Code Pro', Helvetica, Arial;
border-radius: 4px;
}
💡 Lustige Tatsache
Verschachtelte Imports sind sehr nützlich, um Stylesheets von Drittanbietern zu kapseln. Wenn Sie jedoch der Autor des zu importierenden Stylesheets sind, ist es im Allgemeinen besser, Ihre Stile in einem Mixin zu schreiben und dieses Mixin im verschachtelten Kontext einzubinden. Ein Mixin kann flexibler verwendet werden, und es ist beim Betrachten des importierten Stylesheets klarer, wie es verwendet werden soll.
⚠️ Vorsicht!
Der CSS-Code in verschachtelten Imports wird wie ein Mixin ausgewertet. Das bedeutet, dass sich alle Elternselektoren auf den Selektor beziehen, in dem das Stylesheet verschachtelt ist.
SCSS-Syntax
// _theme.scss
ul li {
$padding: 16px;
padding-left: $padding;
[dir=rtl] & {
padding: {
left: 0;
right: $padding;
}
}
}
// style.scss
.theme-sample {
@import "theme";
}
Sass-Syntax
// _theme.sass
ul li
$padding: 16px
padding-left: $padding
[dir=rtl] &
padding:
left: 0
right: $padding
// style.sass
.theme-sample
@import theme
CSS-Ausgabe
.theme-sample ul li {
padding-left: 16px;
}
[dir=rtl] .theme-sample ul li {
padding-left: 0;
padding-right: 16px;
}
Importieren von CSSImportieren von CSS Permalink
- Dart Sass
- seit 1.11.0
- LibSass
- teilweise
- Ruby Sass
- ✗
LibSass unterstützt das Importieren von Dateien mit der Endung .css, aber entgegen der Spezifikation werden sie als SCSS-Dateien behandelt, anstatt als CSS geparst zu werden. Dieses Verhalten wurde als veraltet markiert, und eine Aktualisierung zur Unterstützung des unten beschriebenen Verhaltens ist in Arbeit.
Zusätzlich zum Importieren von .sass- und .scss-Dateien kann Sass auch normale .css-Dateien importieren. Die einzige Regel ist, dass der Import die .css-Endung *nicht* explizit enthalten darf, da diese verwendet wird, um einen Plain-CSS @import anzuzeigen.
SCSS-Syntax
// code.css
code {
padding: .25em;
line-height: 0;
}
// style.scss
@import 'code';
Sass-Syntax
// code.css
code {
padding: .25em;
line-height: 0;
}
// style.sass
@import code
CSS-Ausgabe
code {
padding: .25em;
line-height: 0;
}
CSS-Dateien, die von Sass importiert werden, erlauben keine speziellen Sass-Features. Um sicherzustellen, dass Autoren nicht versehentlich Sass in ihrem CSS schreiben, führen alle Sass-Features, die keine gültigen CSS-Features sind, zu Fehlern. Andernfalls wird der CSS-Code unverändert wiedergegeben. Er kann sogar erweitert werden!
Plain CSS @importsPlain CSS @imports Permalink
- Dart Sass
- ✓
- LibSass
- teilweise
- Ruby Sass
- ✓
Standardmäßig behandelt LibSass Plain CSS-Imports korrekt. Jegliche benutzerdefinierten Importer werden jedoch fälschlicherweise auf Plain-CSS @import-Regeln angewendet, wodurch diese Regeln Sass-Dateien laden können.
Da @import auch in CSS definiert ist, benötigt Sass eine Möglichkeit, Plain CSS @imports zu kompilieren, ohne zu versuchen, die Dateien zur Kompilierungszeit zu importieren. Um dies zu erreichen und sicherzustellen, dass SCSS eine möglichst umfassende Obermenge von CSS ist, kompiliert Sass alle @imports mit den folgenden Merkmalen zu Plain CSS Imports:
- Imports, bei denen die URL mit
.cssendet. - Imports, bei denen die URL mit
http://oderhttps://beginnt. - Imports, bei denen die URL als
url()geschrieben ist. - Imports mit Media Queries.
SCSS-Syntax
@import "theme.css";
@import "http://fonts.googleapis.com/css?family=Droid+Sans";
@import url(theme);
@import "landscape" screen and (orientation: landscape);
Sass-Syntax
@import "theme.css"
@import "http://fonts.googleapis.com/css?family=Droid+Sans"
@import url(theme)
@import "landscape" screen and (orientation: landscape)
CSS-Ausgabe
@import "theme.css";
@import "http://fonts.googleapis.com/css?family=Droid+Sans";
@import url(theme);
@import "landscape" screen and (orientation: landscape);
InterpolationInterpolation Permalink
Obwohl Sass-Imports keine Interpolation verwenden können (um sicherzustellen, dass es immer möglich ist zu erkennen, woher Mixins, Funktionen und Variablen stammen), können Plain CSS-Imports dies. Dies ermöglicht die dynamische Generierung von Imports, beispielsweise basierend auf Mixin- Parametern.
SCSS-Syntax
@mixin google-font($family) {
@import url("http://fonts.googleapis.com/css?family=#{$family}");
}
@include google-font("Droid Sans");
Sass-Syntax
@mixin google-font($family)
@import url("http://fonts.googleapis.com/css?family=#{$family}")
@include google-font("Droid Sans")
CSS-Ausgabe
@import url("http://fonts.googleapis.com/css?family=Droid Sans");
Importieren und ModuleImportieren und Module Permalink
- Dart Sass
- seit 1.23.0
- LibSass
- ✗
- Ruby Sass
- ✗
Nur Dart Sass unterstützt derzeit @use. Benutzer anderer Implementierungen müssen stattdessen die @import-Regel verwenden.
Das Modulsystem von Sass integriert sich nahtlos mit @import, egal ob Sie eine Datei importieren, die @use-Regeln enthält, oder eine Datei laden, die Imports als Modul enthält. Wir möchten den Übergang von @import zu @use so reibungslos wie möglich gestalten.
Importieren einer Modulsystem-DateiImportieren einer Modulsystem-Datei Permalink
Wenn Sie eine Datei importieren, die @use-Regeln enthält, hat die importierende Datei Zugriff auf alle Mitglieder (auch private Mitglieder), die direkt in dieser Datei definiert sind, aber *nicht* auf Mitglieder aus Modulen, die diese Datei geladen hat. Wenn diese Datei jedoch @forward-Regeln enthält, hat die importierende Datei Zugriff auf weitergeleitete Mitglieder. Dies bedeutet, dass Sie eine Bibliothek importieren können, die für die Verwendung mit dem Modulsystem geschrieben wurde.
⚠️ Vorsicht!
Wenn eine Datei mit @use-Regeln importiert wird, wird der gesamte CSS-Code, der transitiv durch diese Regeln geladen wird, in das resultierende Stylesheet aufgenommen, auch wenn er bereits durch einen anderen Import enthalten war. Wenn Sie nicht vorsichtig sind, kann dies zu aufgeblähten CSS-Ausgaben führen!
Nur-Import-DateienNur-Import-Dateien Permalink
Eine API, die für @use sinnvoll ist, ist möglicherweise nicht für @import sinnvoll. Zum Beispiel fügt @use standardmäßig einen Namespace zu allen Mitgliedern hinzu, sodass Sie kurze Namen sicher verwenden können, aber @import tut dies nicht, sodass Sie möglicherweise etwas Längeres benötigen. Wenn Sie Bibliotheksautor sind, sind Sie möglicherweise besorgt, dass Ihre bestehenden @import-Benutzer Probleme bekommen, wenn Sie Ihre Bibliothek auf das neue Modulsystem umstellen, das verwendet.
Um dies zu erleichtern, unterstützt Sass auch *nur-Import-Dateien*. Wenn Sie eine Datei mit dem Namen <name>.import.scss benennen, wird sie nur für Imports geladen, nicht für @uses. Auf diese Weise können Sie die Kompatibilität für @import-Benutzer beibehalten und gleichzeitig eine gute API für Benutzer des neuen Modulsystems bereitstellen.
SCSS-Syntax
// _reset.scss
// Module system users write `@include reset.list()`.
@mixin list() {
ul {
margin: 0;
padding: 0;
list-style: none;
}
}
// _reset.import.scss
// Legacy import users can keep writing `@include reset-list()`.
@forward "reset" as reset-*;
Sass-Syntax
// _reset.sass
// Module system users write `@include reset.list()`.
@mixin list()
ul
margin: 0
padding: 0
list-style: none
// _reset.import.sass
// Legacy import users can keep writing `@include reset-list()`.
@forward "reset" as reset-*
Module über Imports konfigurierenModule über Imports konfigurieren Permalink
- Dart Sass
- seit 1.24.0
- LibSass
- ✗
- Ruby Sass
- ✗
Sie können Module, die über einen @import geladen werden, konfigurieren, indem Sie globale Variablen definieren, bevor Sie den @import verwenden, der dieses Modul zuerst lädt.
SCSS-Syntax
// _library.scss
$color: blue !default;
a {
color: $color;
}
// _library.import.scss
@forward 'library' as lib-*;
// style.sass
$lib-color: green;
@import "library";
Sass-Syntax
$color: blue !default
a
color: $color
// _library.import.sass
@forward 'library' as lib-*
// style.sass
$lib-color: green
@import "library"
CSS-Ausgabe
a {
color: green;
}
⚠️ Vorsicht!
Module werden nur einmal geladen. Wenn Sie also die Konfiguration ändern, nachdem Sie ein Modul zum ersten Mal (auch indirekt) @importiert haben, wird die Änderung ignoriert, wenn Sie das Modul erneut @importieren.
Laden eines Moduls, das Imports enthältLaden eines Moduls, das Imports enthält Permalink
Wenn Sie @use (oder @forward) verwenden, um ein Modul zu laden, das @import verwendet, enthält dieses Modul alle öffentlichen Mitglieder, die vom Stylesheet, das Sie laden, definiert werden, *und* alles, was dieses Stylesheet transitiv importiert. Mit anderen Worten, alles, was importiert wird, wird so behandelt, als wäre es in einem großen Stylesheet geschrieben.
Dies erleichtert die Umstellung auf die Verwendung von @use in einem Stylesheet, selbst bevor alle Bibliotheken, von denen Sie abhängen, auf das neue Modulsystem umgestellt wurden. Beachten Sie jedoch, dass sich ihre APIs wahrscheinlich ändern, wenn sie konvertiert werden!