In diesem Video erklärt Nick Arce, warum viele Websites nach dem Upgrade auf Bricks 2.0 plötzlich merkwürdige Layout- und Styling-Probleme zeigen, was die neue Cascade Layer-Funktion damit zu tun hat und wie man die auftretenden Probleme systematisch findet und behebt. Das Video fasst die Konzepte, die praktischen Schritte und konkrete Lösungen zusammen und führt schrittweise durch typische Fehlerquellen, damit Entwickler und Designer ihre Seiten schnell wieder in Ordnung bringen können.
Viele Anwender bemerkten nach dem Wechsel zu Bricks 2.0 plötzlich, dass Style-Regeln falsch angewendet werden oder Standard-Styles von Bricks scheinbar schwerer zu überschreiben sind. Typische Symptome sind:
- Absätze, die sich über die gesamte Bildschirmbreite erstrecken und dadurch schlecht lesbar sind.
- Drop-down-Menüs oder Mega-Menüs, die auf Mobilgeräten nicht wie erwartet ein- oder ausblenden oder nicht korrekt animieren.
- Eigene global definierte CSS-Regeln, die durch Bricks-Standards scheinbar ignoriert oder durchgestrichen angezeigt werden.
Diese Probleme können frustrierend sein, weil frühere Techniken zur Spezifitäts-Erhöhung plötzlich nicht mehr das erwartete Verhalten erzielen. Die Ursache liegt in der Implementierung der neuen Cascade Layer von Bricks.
Was ist das überhaupt Cascade Layer?
Cascade Layer ist ein Mechanismus, der CSS-Stylesheets in logische Schichten (Layers) organisiert. Bricks 2.0 legt viele seiner Standard-Styles in eine eigene Layer, sodass diese Styles eine andere Priorität im Vergleich zu normalen Stylesheets erhalten. Das Ziel ist sauberer, kontrollierbarer CSS-Einsatz und bessere Performance – aber es bringt auch neue Regeln für die Kaskade mit sich.
Nicks Kernpunkte zum Cascade Layer in einfachen Worten:
- Bricks packt seine Standard-CSS in einen eigenen Layer (z. B. „bricks“).
- Eigene Stylesheets (z. B. globales CSS oder Plugin-Styles) landen in dem impliziten äußeren Layer, der oberhalb des Bricks-Layers liegt.
- Regeln in einem höheren Layer überschreiben Regeln in einem niedrigeren Layer, ungeachtet der Komplexität der Selektoren – solange keine weiteren Faktoren wie !important im Spiel sind.
Das bedeutet konkret: Sind Bricks-Styles in einem eigenen Layer unterhalb des eigenen Stylesheet-Layers, können eigene einfache Selektoren (z. B. p { max-width: 55ch }) die Bricks-Regeln überschreiben, ohne dass man auf spezifischere Selektoren zurückgreifen muss — solange keine !important-Regel aus dem unteren Layer die Oberhand hat.
Konkretes Beispiel mit Absatzbreite
Nick demonstriert das Problem an einem typischen Beispiel: Ein globaler Stil soll alle Absätze auf max-width: 55ch begrenzen, weil das für die Lesbarkeit gut ist. Vorgehen:
- In globales CSS schreiben:
p { max-width: 55ch; } - Speichern und Seite überprüfen – der Absatz bleibt jedoch über die ganze Breite.
- Im Inspector sieht man, dass die Regel durch eine Bricks-Standard-Regel überschrieben wird. Die Bricks-Regel hat eine höhere Spezifität (z. B. selektiert über eine Klasse).
Vor Bricks 2.0 wäre die Lösung gewesen, die eigene Regel spezifischer zu machen (z. B. eine Klasse an alle Absätze zu hängen oder p.some-class { ... }). Das ist allerdings umständlich: man möchte nicht jedem Absatz eine Klasse verpassen. Mit aktiviertem Cascade Layer ist das nicht mehr nötig.
Cascade Layer an/aus
In den Bricks-Einstellungen (Performance Tab) gibt es die Option Cascade Layer. In den Release Candidates war diese Option standardmäßig AUS, in Bricks 2.0 ist sie standardmäßig AN.
Nick betont, dass Bricks die Deaktivierung nicht empfiehlt – und er tut es auch nicht: Cascade Layer hat viele Vorteile. Wichtig ist allerdings, zu verstehen, wie sie die CSS-Kaskade verändert.
Wenn Cascade Layer aktiviert ist:
- Eigene Stylesheets liegen in dem impliziten äußeren Layer (höher).
- Bricks-Standard-Styles liegen in einem „bricks“-Layer (niedriger).
- Eigene Regeln überschreiben die Bricks-Regeln, auch wenn die Bricks-Regeln eine höhere Selektor-Spezifität haben – solange die Bricks-Regeln nicht mit !important markiert sind.
Das war genau die Lösung für das Absatz-Beispiel: nachdem Cascade Layer eingeschaltet und CSS neu generiert wurde, funktionierte die einfache p { max-width: 55ch }-Regel sofort.
Die Stolperfalle — !important in einem unteren Layer
Der komplexere Teil, der viele Nutzer verwirrt, ist wie !important mit Cascade Layers interagiert. Nick zeigt ein reales Problem mit einem Mega-Menu, das auf Mobilgeräten von links herein sliden soll (left bzw. inset-inline-start 100% → 0%) und er zeigt natürlich auch die Lösung für dieses Problem.
