Cascade Layers

Eine neue Sache kommt in CSS: @layer.

Das kommt von Miriam Suzanne, die wirklich auf einer Welle ist, wichtige neue CSS-Sachen zu beeinflussen. Ich habe all das gehört, und dann ist es plötzlich in experimentellen Browsern erschienen.

Bramus hat sich das alles genau angesehen mit einem fantastischen Beitrag dazu.

Mit der Einführung von Cascade Layers werden wir Entwickler mehr Werkzeuge zur Verfügung haben, um die Kaskade zu kontrollieren. Die wahre Stärke von Cascade Layers liegt in ihrer einzigartigen Position in der Kaskade: vor der Selektorspezifität und der Reihenfolge des Erscheinens. Deshalb müssen wir uns keine Gedanken über die Selektorspezifität des CSS machen, das in anderen Layern verwendet wird, noch über die Reihenfolge, in der wir CSS in diese Layer laden – etwas, das für größere Teams oder beim Laden von Drittanbieter-CSS sehr nützlich sein wird.

Bramus Van Damme, „Die Zukunft von CSS: Cascade Layers (CSS @layer)“

Hervorhebung von mir.

Das ist der Kernpunkt: Dies ist eine neue Sache, die beeinflusst, welche Selektoren gewinnen. Es wird einige Umstrukturierungen unserer CSS-Denkweise erfordern, da Layer ein völlig neuer (und mächtiger) Teil der Bestimmung dessen sind, welche Stile tatsächlich angewendet werden.

Ich sage mächtig, weil ein „höherer“ Layer buchstäblich einen traditionell stärkeren Selektor schlagen kann, selbst mit einem schwächeren Selektor im Layer.

/* First layer */
@layer base-layer {
  body#foo {
    background: tan;
  }
}
/* Higher layer, so this wins, despite selector strength */
@layer theme-layer {
  body.foo {
    background: #eee;
  }
}

/* Careful! Unlayered styles are more powerful than layers, even if the selector is weaker */
body {
  background: red;
}

Da das CSS unten nicht in einem Layer ist, gewinnt es, auch mit dem schwächeren Selektor.

Und Sie sind nicht auf einen Layer beschränkt. Sie können sie definieren und so verwenden, wie Sie möchten.

@layer reset;     /* Create 1st layer named “reset” */
@layer base;      /* Create 2nd layer named “base” */
@layer theme;     /* Create 3rd layer named “theme” */
@layer utilities; /* Create 4th layer named “utilities” */
/* Or, @layer reset, base, theme, utilities; */


@layer reset { /* Append to layer named “reset” */
  /* ... */
}

@layer theme { /* Append to layer named “theme” */
  /* ... */
}

@layer base { /* Append to layer named “base” */
  /* ... */
}

@layer theme { /* Append to layer named “theme” */
  /* ... */
}

Wirklich atemberaubend.

Wie werden wir das nutzen?

Ich frage mich, ob ein gängiges Muster entstehen könnte…

1. Layer *alles*, damit die Prioritätsstufen wirklich klar sind. *Vielleicht* unlayered CSS für nur sehr mächtige Überschreibungen zulassen, aber idealerweise auch das als High-Level-Layer.
2. Resets als unterster Layer.
3. Drittanbieter-Sachen als mittlerer/mittlere Layer.
4. Alles, was vom Team erstellt wurde, als höchster Layer.

Sie müssen sich keine Gedanken machen, Platz dazwischen zu lassen (wie Sie es vielleicht mit z-index tun), da Sie ihn anpassen können, ohne jederzeit Zahlen anhängen zu müssen.

Die Zeit wird es zeigen.

Debugging

Ich hoffe, DevTools wird Layer sehr klar darstellen, denn es wird eine Weile lang ernsthaftes Kopfzerbrechen geben, wenn wir schwächer aussehende Selektoren sehen, die wegen der Layer-Platzierung gewinnen.

Browser-Unterstützung

Sieht so aus, als wäre caniuse hier am Ball!

Aktualisierungen

Diese Sachen sind brandneu (zum Zeitpunkt des Schreibens), daher ist Volatilität zu erwarten, nehme ich an. Es sieht so aus, als ob am 6. Oktober 2021 beschlossen wurde, dass *un*layered Styles tatsächlich die stärksten Styles sind, nicht die schwächsten. Ich habe versucht, den Artikel zu aktualisieren, um das zu zeigen.