{"id":363766,"date":"2022-02-21T07:40:35","date_gmt":"2022-02-21T15:40:35","guid":{"rendered":"https:\/\/css-tricks.com\/?p=363766"},"modified":"2022-10-19T12:44:27","modified_gmt":"2022-10-19T19:44:27","slug":"css-cascade-layers","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/css-cascade-layers\/","title":{"rendered":"A Complete Guide to CSS Cascade Layers"},"content":{"rendered":"\n<p>This is your complete guide to CSS cascade layers, a CSS feature that allows us to define explicit contained layers of specificity, so that we have full control over which styles take priority in a project without relying on specificity hacks or <code>!important<\/code>. This guide is intended to help you fully understand what cascade layers are for, how and why you might choose to use them, the current levels of support, and the syntax of how you use them.<\/p>\n\n\n\n<!--more-->\n\n\n<h2 class=\"simpletoc-title \">Table of Contents<\/h2><ul class=\"simpletoc-list\"   >\n<li>\n<a  href=\"#quick-example\">Quick example<\/a><\/li><li>\n<a  href=\"#introduction-what-are-cascade-layers\">Introduction: what are cascade layers?<\/a><\/li><li>\n<a  href=\"#where-do-layers-fit-in-the-cascade\">Where do layers fit in the cascade?<\/a><\/li><li>\n<a  href=\"#important-origins-context-and-layers-are-reversed\">!important origins, context, and layers are reversed!<\/a><\/li><li>\n<a  href=\"#establishing-a-layer-order\">Establishing a layer order<\/a><\/li><li>\n<a  href=\"#syntax-working-with-cascade-layers\">Syntax: Working with cascade layers<\/a><\/li><li>\n<a  href=\"#use-cases-when-would-i-want-to-use-cascade-layers\">Use cases: When would I want to use cascade layers?<\/a><\/li><li>\n<a  href=\"#test-your-knowledge-which-style-wins\">Test your knowledge: Which style wins?<\/a><\/li><li>\n<a  href=\"#debugging-layer-conflicts-in-browser-developer-tools\">Debugging layer conflicts in browser developer tools<\/a><\/li><li>\n<a  href=\"#browser-support-and-fallbacks\">Browser support and fallbacks<\/a><\/li><li>\n<a  href=\"#more-resources\">More resources<\/a><\/li><\/ul>\n<\/li><\/ul>\n\n<h3 class=\"wp-block-heading\" id=\"quick-example\">Quick example<\/h3>\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css ticss-a8840c73\" data-line=\"\"><code markup=\"tt\">\/* establish a layer order up-front, from lowest to highest priority *\/\n@layer reset, defaults, patterns, components, utilities, overrides;\n\n\/* import stylesheets into a layer (dot syntax represents nesting) *\/\n@import url('framework.css') layer(components.framework);\n\n\/* add styles to layers *\/\n@layer utilities {\n  \/* high layer priority, despite low specificity *\/\n  [data-color='brand'] { \n    color: var(--brand, rebeccapurple);\n  }\n}\n\n@layer defaults {\n  \/* higher specificity, but lower layer priority *\/\n  a:any-link { color: maroon; }\n}\n\n\/* un-layered styles have the highest priority *\/\na {\n  color: mediumvioletred;\n}<\/code><\/pre>\n\n\n<h3 class=\"wp-block-heading\" id=\"introduction-what-are-cascade-layers\">Introduction: what are cascade layers?<\/h3>\n\n\n<p>CSS Cascade Layers are intended to solve tricky problems in CSS. Let\u2019s take a look at <strong>the main problem<\/strong> and how cascade layers aim to solve it.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"problem-specificity-conflicts-escalate\">Problem: Specificity conflicts escalate<\/h4>\n\n\n<p>Many of us have been in situations where we want to override styles from elsewhere in our code (or a third-party tool), due to conflicting selectors. And over the years, authors have developed a number of \u201cmethodologies\u201d and \u201cbest practices\u201d to avoid these situations \u2014 such as \u201conly using a single class\u201d for all selectors. These rules are usually more about avoiding the cascade, rather than <a href=\"https:\/\/css-tricks.com\/dont-fight-the-cascade-control-it\/\">putting it to use<\/a>.<\/p>\n\n\n\n<p>Managing cascade conflicts and selector specificity has often been considered one of the harder \u2014 or at least more confusing \u2014 aspects of CSS. That may be partly because few other languages rely on a cascade as their central feature, but it\u2019s also true that the original cascade relies heavily on <em>heuristics<\/em> (an educated-guess or assumption built into the code) rather than providing direct and explicit control to web authors.<\/p>\n\n\n\n<p><dfn>Selector specificity<\/dfn>, for example \u2014 our primary interaction with the cascade \u2014 is based on the assumption that more narrowly targeted styles (like IDs that are only used once) are likely more important than more generic and reusable styles (like classes and attributes). That is to say: how <em>specific<\/em> the selector is. That\u2019s a good guess, but it\u2019s not a totally reliable rule, and that causes some issues:<\/p>\n\n\n\n<ul><li>It combines the act of <em>selecting elements<\/em>, with the act of <em>prioritizing rule-sets<\/em>.<\/li><li>The simplest way to \u2018fix\u2019 a conflict with specificity is to escalate the problem by adding otherwise unnecessary selectors, or (gasp) <a href=\"https:\/\/css-tricks.com\/when-using-important-is-the-right-choice\/\">throwing the<\/a> <a href=\"https:\/\/css-tricks.com\/when-using-important-is-the-right-choice\/\"><code>!important<\/code> hand-grenade<\/a>.<\/li><\/ul>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">.overly#powerful .framework.widget {\n  color: maroon;\n}\n\n.my-single_class { \/* add some IDs to this ??? *\/\n  color: rebeccapurple; \/* add !important ??? *\/\n}<\/code><\/pre>\n\n\n<h4 class=\"wp-block-heading\" id=\"solution-cascade-layers-provide-control\">Solution: cascade layers provide control<\/h4>\n\n\n<p><dfn>Cascade layers<\/dfn> give CSS authors more direct control over the cascade so we can build more intentionally cascading systems without relying as much on heuristic assumptions that are tied to selection.<\/p>\n\n\n\n<p>Using the <code>@layer<\/code> at-rule and layered <code>@import<\/code>s, we can establish our own <em>layers of the cascade<\/em> \u2014 building from low-priority styles like resets and defaults, through themes, frameworks, and design systems, up to highest-priority styles, like components, utilities, and overrides. Specificity is still applied to conflicts <em>within each layer<\/em>, but conflicts between layers are always resolved by using the higher-priority layer styles.<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer framework {\n  .overly#powerful .framework.widget {\n    color: maroon;\n  }\n}\n\n@layer site {\n  .my-single_class {\n    color: rebeccapurple;\n  }\n}<\/code><\/pre>\n\n\n\n<p>These layers are ordered and grouped so that they don\u2019t escalate in the same way that specificity and importance can. Cascade layers aren\u2019t cumulative like selectors. Adding <em>more layers<\/em> doesn\u2019t make something <em>more important<\/em>. They\u2019re also not binary like importance \u2014 suddenly jumping to the top of a stack \u2014 or numbered like <code>z-index<\/code>, where we have to guess a big number (<code>z-index:<\/code> <code>9999999<\/code>?). In fact, by default, layered styles are <em>less important<\/em> than un-layered styles.<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer defaults {\n  a:any-link { color: maroon; }\n}\n\n\/* un-layered styles have the highest priority *\/\na {\n  color: mediumvioletred;\n}<\/code><\/pre>\n\n\n<h3 class=\"wp-block-heading\" id=\"where-do-layers-fit-in-the-cascade\">Where do layers fit in the cascade?<\/h3>\n\n\n<p>The cascade is a series of steps (an algorithm) for resolving conflicts between styles.<\/p>\n\n\n\n<div class=\"wp-block-columns is-layout-flex wp-container-core-columns-is-layout-1 wp-block-columns-is-layout-flex\">\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\">\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">html { --button: teal; }\nbutton { background: rebeccapurple !important; }\n.warning { background: maroon; }<\/code><\/pre>\n<\/div>\n\n\n\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\">\n<pre rel=\"HTML\" class=\"wp-block-csstricks-code-block language-markup\" data-line=\"\"><code markup=\"tt\">&lt;button class=\"warning\" style=\"background: var(--button);\">\n  what color background?\n&lt;\/button><\/code><\/pre>\n<\/div>\n<\/div>\n\n\n\n<p>With the addition of cascade layers, those steps are:<\/p>\n\n\n\n<img decoding=\"async\" src=\"https:\/\/css-tricks.com\/wp-content\/uploads\/2022\/02\/layers-tall-outlines2.svg\" alt=\"Illustration of the various specificity levels of the CSS cascade and where CSS Cascade Layers fit in it.\" width=\"650\">\n\n\n\n<div style=\"height:26px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p><em>Selector specificity<\/em> is only one small part of the cascade, but it\u2019s also the step we interact with most, and is often used to refer more generally to overall <em>cascade priority<\/em>. People might say that the <code>!important<\/code> flag or the <code>style<\/code> attribute \u201cadds specificity\u201d \u2014 a quick way of expressing that the style becomes higher priority in the cascade. Since cascade layers have been added directly above specificity, it\u2019s reasonable to think about them in a similar way: one step more powerful than ID selectors.<\/p>\n\n\n\n<p>However, CSS Cascade Layers also make it more essential that we fully understand the role of <code>!important<\/code> in the cascade \u2014 not just as a tool for \u201cincreasing specificity\u201d but as a system for balancing concerns.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"important-origins-context-and-layers-are-reversed\"><code>!important<\/code> origins, context, and layers are reversed!<\/h3>\n\n\n<p>As web authors, we often think of <code>!important<\/code> as a way of increasing specificity, to override inline styles or highly specific selectors. That works OK in most cases (if you\u2019re OK with the escalation) but it leaves out the primary purpose of <em>importance<\/em> as a feature in the overall cascade.<\/p>\n\n\n\n<p>Importance isn\u2019t there to simply increase power \u2014 but to balance the power between various competing concerns.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"important-origins\">Important origins<\/h4>\n\n\n<p>It all starts with <dfn>origins<\/dfn>, where a style comes from in the web ecosystem. There are three basic origins in CSS:<\/p>\n\n\n\n<ul><li>The <strong>browser<\/strong> (or user agent)<\/li><li>The <strong>user<\/strong> (often via browser preferences)<\/li><li>Web <strong>authors<\/strong> (that\u2019s us!)<\/li><\/ul>\n\n\n\n<p>Browsers provide readable defaults for all the elements, and then users set their preferences, and then we (authors) provide the intended design for our web pages. So, by default, browsers have the lowest priority, user preferences override the browser defaults, and we\u2019re able to override everyone.<\/p>\n\n\n\n<p>But the creators of CSS were very clear that we should not actually have the final word:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>If conflicts arise <strong>the user should have the last word<\/strong>, but one should also allow the author to attach style hints.<\/p><cite>\u2014 H\u00e5kon Lie (emphasis added)<\/cite><\/blockquote>\n\n\n\n<p>So <em>importance<\/em> provides a way for the browser and users to re-claim their priority when it matters most. When the <code>!important<\/code> flag is added to a style, three new layers are created \u2014 and the order is reversed!<\/p>\n\n\n\n<ol><li><code>!important<\/code> browser styles (most powerful)<\/li><li><code>!important<\/code> user preferences<\/li><li><code>!important<\/code> author styles<\/li><li>normal author styles<\/li><li>normal user preferences<\/li><li>normal browser styles (least powerful)<\/li><\/ol>\n\n\n\n<p>For us, adding <code>!important<\/code> doesn\u2019t change much \u2014 our important styles are pretty close to our normal styles \u2014 but for the browser and user it\u2019s a very powerful tool for regaining control. Browser default style sheets include a number of important styles that it would be impossible for us to override, such as:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">iframe:fullscreen {\n  \/* iframes in full-screen mode don't show a border. *\/\n  border: none !important;\n  padding: unset !important;\n}<\/code><\/pre>\n\n\n\n<p>While most of the popular browsers have made it difficult to upload actual user stylesheets, they all offer user preferences: a graphic interface for establishing specific user styles. In that interface, there is always a checkbox available for users to choose if a site is allowed to override their preferences or not. This is the same as setting <code>!important<\/code> in a user stylesheet:<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1320\" height=\"996\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643829199568_ScreenShot2022-02-02at12.11.33PM.jpg?resize=1320%2C996&#038;ssl=1\" alt=\"Screenshot of user font preferences.\" class=\"wp-image-363777\" srcset=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643829199568_ScreenShot2022-02-02at12.11.33PM.jpg?w=1320&amp;ssl=1 1320w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643829199568_ScreenShot2022-02-02at12.11.33PM.jpg?resize=300%2C226&amp;ssl=1 300w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643829199568_ScreenShot2022-02-02at12.11.33PM.jpg?resize=1024%2C773&amp;ssl=1 1024w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643829199568_ScreenShot2022-02-02at12.11.33PM.jpg?resize=768%2C579&amp;ssl=1 768w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643829199568_ScreenShot2022-02-02at12.11.33PM.jpg?resize=1000%2C755&amp;ssl=1 1000w\" sizes=\"(min-width: 735px) 864px, 96vw\" data-recalc-dims=\"1\" \/><\/figure>\n\n\n<h4 class=\"wp-block-heading\" id=\"important-context\">Important context<\/h4>\n\n\n<p>The same basic logic is applied to <em>context<\/em> in the cascade. By default, styles from the host document (light DOM) override styles from an embedded context (shadow DOM). However, adding <code>!important<\/code> reverses the order:<\/p>\n\n\n\n<ol><li><code>!important<\/code> shadow context (most powerful)<\/li><li><code>!important<\/code> host context<\/li><li>normal host context<\/li><li>normal shadow context (least powerful)<\/li><\/ol>\n\n\n\n<p>Important styles that come from inside a shadow context override important styles defined by the host document. Here\u2019s an <code>odd-bird<\/code> <a href=\"https:\/\/css-tricks.com\/an-introduction-to-web-components\/\">custom element<\/a> with some styles written in the element template (shadow DOM), and some styles in the host page (light DOM) stylesheet:<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_RwjRrEE\" src=\"\/\/codepen.io\/anon\/embed\/RwjRrEE?height=450&amp;theme-id=1&amp;slug-hash=RwjRrEE&amp;default-tab=css,result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed RwjRrEE\" title=\"CodePen Embed RwjRrEE\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n\n<p>Both <code>color<\/code> declarations have normal importance, and so the host page <code>mediumvioletred<\/code> takes priority. But the <code>font-family<\/code> declarations are flagged <code>!important<\/code>, giving advantage to the shadow-context, where <code>fantasy<\/code> is defined.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"important-layers\">Important layers<\/h4>\n\n\n<p>Cascade layers work the same way as both origins and context, with the important layers in reverse-order. The only difference is that layers make that behavior much more noticeable.<\/p>\n\n\n\n<p>Once we start using cascade layers, we will need to be much more cautious and intentional about how we use <code>!important<\/code>. It\u2019s no longer a quick way to jump to the top of the priorities \u2014 but an integrated part of our cascade layering; a way for lower layers to <em>insist<\/em> that some of their styles are essential.<\/p>\n\n\n\n<p>Since cascade layers are customizable, there\u2019s no pre-defined order. But we can imagine starting with three layers:<\/p>\n\n\n\n<ol><li>utilities (most powerful)<\/li><li>components<\/li><li>defaults (least powerful)<\/li><\/ol>\n\n\n\n<p>When styles in those layers are marked as important, they would generate three new, reversed important layers:<\/p>\n\n\n\n<ol><li><code>!important<\/code> defaults (most powerful)<\/li><li><code>!important<\/code> components<\/li><li><code>!important<\/code> utilities<\/li><li>normal utilities<\/li><li>normal components<\/li><li>normal defaults (least powerful)<\/li><\/ol>\n\n\n\n<p>In this example, the color is defined by all three normal layers, and the <code>utilities<\/code> layer wins the conflict, applying the <code>maroon<\/code> color, as the <code>utilities<\/code> layer has a higher priority in <code>@layers<\/code>. But notice that the <code>text-decoration<\/code> property is marked <code>!important<\/code> in both the <code>defaults<\/code> and <code>components<\/code> layers, where important <code>defaults<\/code> take priority, applying the underline declared by <code>defaults<\/code>:<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_mdqEEzB\" src=\"\/\/codepen.io\/anon\/embed\/mdqEEzB?height=450&amp;theme-id=1&amp;slug-hash=mdqEEzB&amp;default-tab=css,result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed mdqEEzB\" title=\"CodePen Embed mdqEEzB\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n<h3 class=\"wp-block-heading\" id=\"establishing-a-layer-order\">Establishing a layer order<\/h3>\n\n\n<p>We can create any number of layers and name them or group them in various ways. But the most important thing to do is to make sure our layers are applied in the right order of priority.<\/p>\n\n\n\n<p>A single layer can be used multiple times throughout the codebase \u2014 cascade layers stack in the order they <em>first appear<\/em>. The first layer encountered sits at the bottom (least powerful), and the last layer at the top (most powerful). But then, above that, <strong>un-layered styles have the highest priority<\/strong>:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer layer-1 { a { color: red; } }\n@layer layer-2 { a { color: orange; } }\n@layer layer-3 { a { color: yellow; } }\n\/* un-layered *\/ a { color: green; }<\/code><\/pre>\n\n\n\n<ol><li>un-layered styles (most powerful)<\/li><li>layer-3<\/li><li>layer-2<\/li><li>layer-1 (least powerful)<\/li><\/ol>\n\n\n\n<p>Then, as discussed above, any important styles are applied in a reverse order:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer layer-1 { a { color: red !important; } }\n@layer layer-2 { a { color: orange !important; } }\n@layer layer-3 { a { color: yellow !important; } }\n\/* un-layered *\/ a { color: green !important; }<\/code><\/pre>\n\n\n\n<ol><li><code>!important<\/code> layer-1 (most powerful)<\/li><li><code>!important<\/code> layer-2<\/li><li><code>!important<\/code> layer-3<\/li><li><code>!important<\/code> un-layered styles<\/li><li>normal un-layered styles<\/li><li>normal layer-3<\/li><li>normal layer-2<\/li><li>normal layer-1 (least powerful)<\/li><\/ol>\n\n\n\n<p>Layers can also be grouped, allowing us to do more complicated sorting of top-level and nested layers:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer layer-1 { a { color: red; } }\n@layer layer-2 { a { color: orange; } }\n@layer layer-3 {\n  @layer sub-layer-1 { a { color: yellow; } }\n  @layer sub-layer-2 { a { color: green; } }\n  \/* un-nested *\/ a { color: blue; }\n}\n\/* un-layered *\/ a { color: indigo; }<\/code><\/pre>\n\n\n\n<ol><li>un-layered styles (most powerful)<\/li><li>layer-3<ol><li>layer-3 un-nested<\/li><li>layer-3 sub-layer-2<\/li><li>layer-3 sub-layer-1<\/li><\/ol><\/li><li>layer-2<\/li><li>layer-1 (least powerful)<\/li><\/ol>\n\n\n\n<p class=\"is-style-explanation\">Grouped layers always stay together in the final layer order (for example, sub-layers of layer-3 will all be next to each other), but this otherwise behaves the same as if the list was \u201cflattened\u201d \u2014 turning this into a single six-item list. When reversing <code>!important<\/code> layer order, the entire list flattened is reversed.<\/p>\n\n\n\n<p>But layers don\u2019t have to be defined once in a single location. We give them names so that layers can be defined in one place (to establish layer order), and then we can append styles to them from anywhere:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* describe the layer in one place *\/\n@layer my-layer;\n\n\/* append styles to it from anywhere *\/\n@layer my-layer { a { color: red; } }<\/code><\/pre>\n\n\n\n<p>We can even define a whole ordered list of layers in a single declaration:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer one, two, three, four, five, etc;<\/code><\/pre>\n\n\n\n<p>This makes it possible for the author of a site to have final say over the layer order. By providing a layer order up-front, before any third party code is imported, the order can be established and rearranged in one place without worrying about how layers are used in any third-party tool.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"syntax-working-with-cascade-layers\">Syntax: Working with cascade layers<\/h3>\n\n\n<p>Let\u2019s take a look at the syntax!<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"order-setting-layer-statements\">Order-setting <code>@layer<\/code> statements<\/h4>\n\n\n<p>Since layers are stacked in the order they are defined, it\u2019s important that we have a tool for establishing that order all in one place!<\/p>\n\n\n\n<p>We can use <code>@layer<\/code> statements to do that. The syntax is:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer &lt;layer-name>#;<\/code><\/pre>\n\n\n\n<p>That hash (<code>#<\/code>) means we can add as many layer names as we want in a comma-separated list:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer reset, defaults, framework, components, utilities;<\/code><\/pre>\n\n\n\n<p>That will establish the layer order:<\/p>\n\n\n\n<ol><li>un-layered styles (most powerful)<\/li><li>utilities<\/li><li>components<\/li><li>framework<\/li><li>defaults<\/li><li>reset (least powerful)<\/li><\/ol>\n\n\n\n<p>We can do this as many times as we want, but remember: what matters is the order each name <em>first appears<\/em>. So this will have the same result:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer reset, defaults, framework;\n@layer components, defaults, framework, reset, utilities;<\/code><\/pre>\n\n\n\n<p>The ordering logic will ignore the order of <code>reset<\/code>, <code>defaults<\/code>, and <code>framework<\/code> in the second <code>@layer<\/code> rule because those layers have already been established. This <code>@layer<\/code> list syntax doesn\u2019t add any special magic to the layer ordering logic: layers are stacked based on <em>the order in which the layers first appear in your code<\/em>. In this case, <code>reset<\/code> appears first in the first <code>@layer<\/code> list. Any <code>@layer<\/code> statement that comes later can only append layer names to the list, <em>but can\u2019t move layers that already exist<\/em>. This ensures that you can always control the final overall layer order from one location \u2014 at the very start of your styles.<\/p>\n\n\n\n<p>These layer-ordering statements are allowed at the top of a stylesheet, before the <code>@import<\/code> rule (but not between imports). We highly recommend using this feature to establish all your layers up-front in a single place so you always know where to look or make changes.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"block-layer-rules\">Block <code>@layer<\/code> rules<\/h4>\n\n\n<p>The block version of the <code>@layer<\/code> rule only takes a single layer name, but then allows you to add styles to that layer:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer &lt;layer-name> {\n  \/* styles added to the layer *\/\n}<\/code><\/pre>\n\n\n\n<p>You can put most things inside an <code>@layer<\/code> block \u2014 media queries, selectors and styles, support queries, etc. The only things you can\u2019t put inside a layer block are things like charset, imports, and namespaces. But don\u2019t worry, there is a syntax for importing styles into a layer.<\/p>\n\n\n\n<p>If the layer name hasn\u2019t been established before, this layer rule will add it to the layer order. But if the name has been established, this allows you to add styles to existing layers from anywhere in the document \u2014 without changing the priority of each layer.<\/p>\n\n\n\n<p>If we\u2019ve established our layer-order up-front with the layer statement rule, we no longer need to worry about the order of these layer blocks:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* establish the order up-front *\/\n@layer defaults, components, utilities;\n\n\/* add styles to layers in any order *\/\n@layer utilities {\n  [hidden] { display: none; }\n}\n\n\/* utilities will override defaults, based on established order *\/\n@layer defaults {\n  * { box-sizing: border-box; }\n  img { display: block; }\n}<\/code><\/pre>\n\n\n<h4 class=\"wp-block-heading\" id=\"grouping-nested-layers\">Grouping (nested) layers<\/h4>\n\n\n<p>Layers can be grouped, by nesting layer rules:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer one {\n  \/* sorting the sub-layers *\/\n  @layer two, three;\n\n  \/* styles ... *\/\n  @layer three { \/* styles ... *\/ }\n  @layer two { \/* styles ... *\/ }\n}<\/code><\/pre>\n\n\n\n<p>This generates grouped layers that can be represented by joining the parent and child names with a period. That means the resulting sub-layers can also be accessed directly from outside the group:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* sorting nested layers directly *\/\n@layer one.two, one.three;\n\n\/* adding to nested layers directly *\/\n@layer one.three { \/* ... *\/ }\n@layer one.two { \/* ... *\/ }<\/code><\/pre>\n\n\n\n<p>The rules of layer-ordering apply at each level of nesting. Any styles that are not further nested are considered \u201cun-layered\u201d in that context, and have priority over further nested styles:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer defaults {\n  \/* un-layered defaults (higher priority) *\/\n  :any-link { color: rebeccapurple; }\n\n  \/* layered defaults (lower priority) *\/\n  @layer reset {\n    a[href] { color: blue; }\n  }\n}<\/code><\/pre>\n\n\n\n<p>Grouped layers are also contained within their parent, so that the layer order does not intermix across groups. In this example, the top level layers are sorted first, and then the layers are sorted within each group:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer reset.type, default.type, reset.media, default.media;<\/code><\/pre>\n\n\n\n<p>Resulting in a layer order of:<\/p>\n\n\n\n<ul><li><em>un-layered<\/em> (most powerful)<\/li><li>default group<ul><li>default <em>un-layered<\/em><\/li><li>default.media<\/li><li>default.type<\/li><\/ul><\/li><li>reset group<ul><li>reset <em>un-layered<\/em><\/li><li>reset.media<\/li><li>reset.type<\/li><\/ul><\/li><\/ul>\n\n\n\n<p>Note that layer names are also scoped so that they don\u2019t interact or conflict with similarly-named layers outside their nested context. Both groups can have distinct <code>media<\/code> sub-layers.<\/p>\n\n\n\n<p>This grouping becomes especially important when using <code>@import<\/code> or <code>&lt;link&gt;<\/code> to layer entire stylesheets. A third-party tool, like <a href=\"https:\/\/getbootstrap.com\" rel=\"noopener\">Bootstrap<\/a>, could use layers internally \u2014 but we can nest those layers into a shared <code>bootstrap<\/code> layer-group on import, to avoid potential layer-naming conflicts.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"layering-entire-stylesheets-with-import-or-link\">Layering entire stylesheets with <code>@import<\/code> or <code>&lt;link&gt;<\/code><\/h4>\n\n\n<p>Entire stylesheets can be added to a layer using the new <code>layer()<\/code> function syntax with <code>@import<\/code> rules:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* styles imported into to the &lt;layer-name> layer *\/\n@import url('example.css') layer(&lt;layer-name>);<\/code><\/pre>\n\n\n\n<p>There is also a proposal to add a <code>layer<\/code> attribute in the HTML <code>&lt;link&gt;<\/code> element \u2014 although this is still under development, and <a href=\"https:\/\/css.oddbird.net\/layers\/guide\/#assigning-layers-in-html-with-the-link-tag\" rel=\"noopener\">not yet supported anywhere<\/a>. This can be used to import third-party tools or component libraries, while grouping any internal layers together under a single layer name \u2014 or as a way of organizing layers into distinct files.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"anonymous-un-named-layers\">Anonymous (un-named) layers<\/h4>\n\n\n<p><dfn>Layer names<\/dfn> are helpful as they allow us to access the same layer from multiple places for sorting or combining layer blocks \u2014 but they are not required.<\/p>\n\n\n\n<p>It\u2019s possible to create <em>anonymous<\/em> (un-named) layers using the block layer rule:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer { \/* ... *\/ }\n@layer { \/* ... *\/ }<\/code><\/pre>\n\n\n\n<p>Or using the import syntax, with a <code>layer<\/code> keyword in place of the <code>layer()<\/code> function:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* styles imported into to a new anonymous layer *\/\n@import url('..\/example.css') layer;<\/code><\/pre>\n\n\n\n<p>Each anonymous layer is unique, and added to the layer order where it is encountered. Anonymous layers can\u2019t be referenced from other layer rules for sorting or appending more styles.<\/p>\n\n\n\n<p>These should probably be used sparingly, but there might be a few use cases:<\/p>\n\n\n\n<ul><li>Projects could ensure that all styles for a given layer are required to be located in a single place.<\/li><li>Third-party tools could \u201chide\u201d their internal layering inside anonymous layers so that they don\u2019t become part of the tool\u2019s public API.<\/li><\/ul>\n\n\n<h4 class=\"wp-block-heading\" id=\"reverting-values-to-the-previous-layer\">Reverting values to the previous layer<\/h4>\n\n\n<p>There are several ways that we can use to &#8220;revert&#8221; a style in the cascade to a previous value, defined by a lower priority origin or layer. That includes a number of existing global CSS values, and a new <code>revert-layer<\/code> keyword that will also be global (works on any property).<\/p>\n\n\n<h5 class=\"wp-block-heading\" id=\"context-existing-global-cascade-keywords\">Context: Existing global cascade keywords*<\/h5>\n\n\n<p>CSS has several <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/CSS\/all#values\" rel=\"noopener\">global keywords<\/a> which can be used on any property to help roll-back the cascade in various ways.<\/p>\n\n\n\n<ul><li><code><strong>initial<\/strong><\/code> sets a property to the <em>specified<\/em> value before any styles (including browser defaults) are applied. This can be surprising as we often think of browser styles as the initial value \u2014 but, for example, the <code>initial<\/code> value of <code>display<\/code> is <code>inline<\/code>, no matter what element we use it on.<\/li><li><code><strong>inherit<\/strong><\/code> sets the property to apply a value from its parent element. This is the default for inherited properties, but can still be used to remove a previous value.<\/li><li><code><strong>unset<\/strong><\/code> acts as though simply removing all previous values \u2014 so that inherited properties once again <code>inherit<\/code>, while non-inherited properties return to their <code>initial<\/code> value.<\/li><li><code><strong>revert<\/strong><\/code> only removes values that we\u2019ve applied in the author origin (i.e. the site styles). This is what we want in most cases, since it allows the browser and user styles to remain intact.<\/li><\/ul>\n\n\n<h5 class=\"wp-block-heading\" id=\"new-the-revert-layer-keyword\">New: the <code>revert-layer<\/code> keyword<\/h5>\n\n\n<p>Cascade layers add a new global <code>revert-layer<\/code> keyword. It works the same as <code>revert<\/code>, but only removes values that we\u2019ve applied in the current cascade layer. We can use that to roll back the cascade, and use whatever value was defined in the previous layers.<\/p>\n\n\n\n<p>In this example, the <code>no-theme<\/code> class removes any values set in the <code>theme<\/code> layer.<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer default {\n  a { color: maroon; }\n}\n\n@layer theme {\n  a { color: var(--brand-primary, purple); }\n\n  .no-theme {\n    color: revert-layer;\n  }\n}<\/code><\/pre>\n\n\n\n<p>So a link tag with the <code>.no-theme<\/code> class will roll back to use the value set in the <code>default<\/code> layer. When <code>revert-layer<\/code> is used in un-layered styles, it behaves the same as <code>revert<\/code> \u2014 rolling back to the previous origin.<\/p>\n\n\n<h5 class=\"wp-block-heading\" id=\"reverting-important-layers\">Reverting important layers<\/h5>\n\n\n<p>Things get interesting if we add <code>!important<\/code> to the <code>revert-layer<\/code> keyword. Because each layer has two distinct \u201cnormal\u201d and \u201cimportant\u201d <a href=\"https:\/\/css.oddbird.net\/layers\/guide\/#important-layers\" rel=\"noopener\">positions in the cascade<\/a>, this doesn\u2019t simply change the priority of the declaration \u2014 it changes what layers are reverted.<\/p>\n\n\n\n<p>Let\u2019s assume we have three layers defined, in a layer stack that looks like this:<\/p>\n\n\n\n<ol><li>utilities (most powerful)<\/li><li>components<\/li><li>defaults (least powerful)<\/li><\/ol>\n\n\n\n<p>We can flesh that out to include not just normal and important positions of each layer, but also un-layered styles, and animations:<\/p>\n\n\n\n<ol><li><code>!important<\/code> defaults (most powerful)<\/li><li><code>!important<\/code> components<\/li><li><code>!important<\/code> utilities<\/li><li><code>!important<\/code> un-layered styles<\/li><li>CSS animations<\/li><li>normal un-layered styles<\/li><li>normal utilities<\/li><li>normal components<\/li><li>normal defaults (least powerful)<\/li><\/ol>\n\n\n\n<p>Now, when we use <code>revert-layer<\/code> in a normal layer (let\u2019s use <code>utilities<\/code>) the result is fairly direct. We revert <em>only that layer<\/em>, while everything else applies normally:<\/p>\n\n\n\n<ol><li>&#x2705; <code>!important<\/code> defaults (most powerful)<\/li><li>&#x2705; <code>!important<\/code> components<\/li><li>&#x2705; <code>!important<\/code> utilities<\/li><li>&#x2705; <code>!important<\/code> un-layered styles<\/li><li>&#x2705; CSS animations<\/li><li>&#x2705; normal un-layered styles<\/li><li>&#x274c; normal utilities<\/li><li>&#x2705; normal components<\/li><li>&#x2705; normal defaults (least powerful)<\/li><\/ol>\n\n\n\n<p>But when we move that <code>revert-layer<\/code> into the important position, we revert both the normal and important versions <em>along with everything in-between<\/em>:<\/p>\n\n\n\n<ol><li>&#x2705; <code>!important<\/code> defaults (most powerful)<\/li><li>&#x2705; <code>!important<\/code> components<\/li><li>&#x274c; <code>!important<\/code> utilities<\/li><li>&#x274c; <code>!important<\/code> un-layered styles<\/li><li>&#x274c; CSS animations<\/li><li>&#x274c; normal un-layered styles<\/li><li>&#x274c; normal utilities<\/li><li>&#x2705; normal components<\/li><li>&#x2705; normal defaults (least powerful)<\/li><\/ol>\n\n\n<h3 class=\"wp-block-heading\" id=\"use-cases-when-would-i-want-to-use-cascade-layers\">Use cases: When would I want to use cascade layers?<\/h3>\n\n\n<p>So what sort of situations might we find ourselves using cascade layers? Here are several examples of when cascade layers make a lot of sense, as well as others where they <em>do not<\/em> make a lot sense.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"less-intrusive-resets-and-defaults\">Less intrusive resets and defaults<\/h4>\n\n\n<p>One of the clearest initial use cases would be to make low-priority defaults that are easy to override.<\/p>\n\n\n\n<p>Some resets have been doing this already by applying the <code>:where()<\/code> pseudo-class around each selector. <code>:where()<\/code> removes all specificity from the selectors it is applied to, which has the basic impact desired, but also some downsides:<\/p>\n\n\n\n<ul><li>It has to be applied to each selector individually<\/li><li>Conflicts inside the reset have to be resolved without specificity<\/li><\/ul>\n\n\n\n<p>Layers allow us to more simply wrap the entire reset stylesheet, either using the block <code>@layer<\/code> rule:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* reset.css *\/\n@layer reset {\n  \/* all reset styles in here *\/\n}<\/code><\/pre>\n\n\n\n<p>Or when you import the reset:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* reset.css *\/\n@import url(reset.css) layer(reset);<\/code><\/pre>\n\n\n\n<p class=\"is-style-explanation\">Or both! Layers can be nested without changing their priority. This way, you can use a third-party reset, and ensure it gets added to the layer you want whether or not the reset stylesheet itself is written using layers internally.<\/p>\n\n\n\n<p>Since layered styles have a lower priority than default \u201cun-layered\u201d styles, this is a good way to start using cascade layers without re-writing your entire CSS codebase.<\/p>\n\n\n\n<p>The reset selectors still have specificity information to help resolve internal conflicts, without wrapping each individual selector \u2014 but you also get the desired outcome of a reset stylesheet that is easy to override.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"managing-a-complex-css-architecture\">Managing a complex CSS architecture<\/h4>\n\n\n<p>As projects become larger and more complex, it can be useful to define clearer boundaries for naming and organizing CSS code. But the more CSS we have, the more potential we have for conflicts \u2014 especially from different parts of a system like a \u201ctheme\u201d or a \u201ccomponent library\u201d or a set of \u201cutility classes.\u201d<\/p>\n\n\n\n<p>Not only do we want these organized by function, but it can also be useful to organize them based on what parts of the system take priority in the case of a conflict. <a href=\"https:\/\/csswizardry.com\/2018\/11\/itcss-and-skillshare\/\" rel=\"noopener\">Harry Robert\u2019s Inverted Triangle CSS<\/a> does a good job visualizing what those layers might contain.<\/p>\n\n\n\n<figure class=\"wp-block-image is-resized ticss-818e5b53\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/paper-attachments.dropbox.com\/s_B537A5BED99F493B05AC662831B02D71D0E588F0E159BD62B299D5F9F4173CB4_1644605716738_itcss-layers2.svg\" alt=\"\" width=\"650\" height=\"389\"\/><\/figure>\n\n\n\n<p>In fact, the initial pitch for adding layers to the CSS cascade used the ITCSS methodology as a primary example, and a guide for developing the feature.<\/p>\n\n\n\n<p>There is no particular technique required for this, but it\u2019s likely helpful to restrict projects to a pre-defined set of top-level layers and then extend that set with nested layers as appropriate.<\/p>\n\n\n\n<p>For example:<\/p>\n\n\n\n<ol><li><strong>low level reset<\/strong> and normalization styles<\/li><li><strong>element defaults<\/strong>, for basic typography and legibility<\/li><li><strong>themes<\/strong>, like light and dark modes<\/li><li><strong>re-usable patterns<\/strong> that might appear across multiple components<\/li><li><strong>layouts<\/strong> and larger page structures<\/li><li>individual <strong>components<\/strong><\/li><li><strong>overrides<\/strong> and <strong>utilities<\/strong><\/li><\/ol>\n\n\n\n<p>We can create that top-level layer stack at the very start of our CSS, with a single layer statement:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer\n  reset,\n  default,\n  themes,\n  patterns,\n  layouts,\n  components,\n  utilities;<\/code><\/pre>\n\n\n\n<p>The exact layers needed, and how you name those layers, might change from one project to the next.<\/p>\n\n\n\n<p>From there, we create even more detailed layer breakdowns. Maybe our components themselves have defaults, structures, themes, and utilities internally.<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer components {\n  @layer defaults, structures, themes, utilities;\n}<\/code><\/pre>\n\n\n\n<p>Without changing the top-level structure, we now have a way to further layer the styles within each component.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"using-third-party-tools-and-frameworks\">Using third-party tools and frameworks<\/h4>\n\n\n<p>Integrating third-party CSS with a project is one of the most common places to run into cascade issues. Whether we\u2019re using a shared reset like Normalizer or CSS Remedy, a generic design system like Material Design, a framework like Bootstrap, or a utility toolkit like Tailwind \u2014 we can\u2019t always control the selector specificity or importance of all the CSS being used on our sites. Sometimes, this even extends to internal libraries, design systems, and tools managed elsewhere in an organization.<\/p>\n\n\n\n<p>As a result, we often have to structure our internal CSS around the third-party code, or escalate conflicts when they come up \u2014 with artificially high specificity or <code>!important<\/code> flags. And then we have to maintain those hacks over time, adapting to upstream changes.<\/p>\n\n\n\n<p>Cascade layers give us a way to slot third-party code into the cascade of any project exactly where we want it to live \u2014 no matter how selectors are written internally. Depending on the type of library we\u2019re using, we might do that in various ways. Let\u2019s start with a basic layer-stack, working our way up from resets to utilities:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer reset, type, theme, components, utilities;<\/code><\/pre>\n\n\n\n<p>And then we can incorporate some tools\u2026<\/p>\n\n\n<h5 class=\"wp-block-heading\" id=\"using-a-reset\">Using a reset<\/h5>\n\n\n<p>If we\u2019re using a tool like <a href=\"https:\/\/css-tricks.com\/css-remedy\/\">CSS Remedy<\/a>, we might also have some reset styles of our own that we want to include. Let\u2019s import CSS Remedy into a sub-layer of <code>reset<\/code>:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@import url('remedy.css') layer(reset.remedy);<\/code><\/pre>\n\n\n\n<p>Now we can add our own reset styles to the <code>reset<\/code> layer, without any further nesting (unless we want it). Since styles directly in <code>reset<\/code> will override any further nested styles, we can be sure our styles will always take priority over CSS Remedy if there\u2019s a conflict \u2014 no matter what changes in a new release:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@import url('remedy.css') layer(reset.remedy);\n\n@layer reset {\n  :is(ol, ul)[role='list'] {\n    list-style: none;\n    padding-inline-start: 0;\n  }\n}<\/code><\/pre>\n\n\n\n<p>And since the <code>reset<\/code> layer is at the bottom of the stack, the rest of the CSS in our system will override both Remedy, and our own local reset additions.<\/p>\n\n\n<h5 class=\"wp-block-heading\" id=\"using-utility-classes\">Using utility classes<\/h5>\n\n\n<p>At the other end of our stack, \u201cutility classes\u201d in CSS can be a useful way to reproduce common patterns (like additional context for screen readers) in a broadly-applicable way. Utilities tend to break the specificity heuristic, since we want them defined broadly (resulting in a low specificity), but we also generally want them to \u201cwin\u201d conflicts.<\/p>\n\n\n\n<p>By having a <code>utilities<\/code> layer at the top of our layer stack, we can make that possible. We can use that in a similar way to the reset example, both loading external utilities into a sub-layer, and providing our own:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@import url('tailwind.css') layer(utilities.tailwind);\n\n@layer utilities {\n  \/* from https:\/\/kittygiraudel.com\/snippets\/sr-only-class\/ *\/\n  \/* but with !important removed from the properties *\/\n  .sr-only {\n    border: 0;\n    clip: rect(1px, 1px, 1px, 1px);\n    -webkit-clip-path: inset(50%);\n    clip-path: inset(50%);\n    height: 1px;\n    overflow: hidden;\n    margin: -1px;\n    padding: 0;\n    position: absolute;\n    width: 1px;\n    white-space: nowrap;\n  }\n}<\/code><\/pre>\n\n\n<h5 class=\"wp-block-heading\" id=\"using-design-systems-and-component-libraries\">Using design systems and component libraries<\/h5>\n\n\n<p>There are a lot of CSS tools that fall somewhere in the middle of our layer stack \u2014 combining typography defaults, themes, components, and other aspects of a system.<\/p>\n\n\n\n<p>Depending on the particular tool, we might do something similar to the reset and utility examples above \u2014 but there are a few other options. A highly integrated tool might deserve a top-level layer:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer reset, bootstrap, utilities;\n@import url('bootstrap.css') layer(bootstrap);<\/code><\/pre>\n\n\n\n<p>If these tools start to provide layers as part of their public API, we could also break it down into parts \u2014 allowing us to intersperse our code with the library:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@import url('bootstrap\/reset.css') layer(reset.bootstrap);\n@import url('bootstrap\/theme.css') layer(theme.bootstrap);\n@import url('bootstrap\/components.css') layer(components.bootstrap);\n\n@layer theme.local {\n  \/* styles here will override theme.bootstrap *\/\n  \/* but not interfere with styles from components.bootstrap *\/\n}<\/code><\/pre>\n\n\n<h4 class=\"wp-block-heading\" id=\"using-layers-with-existing-un-layered-important-filled-frameworks\">Using layers with existing (un-layered, !important-filled) frameworks<\/h4>\n\n\n<p>As with any major language change, there\u2019s going to be an adjustment period when CSS Cascade Layers become widely adopted. What happens if your team is ready to start using layers next month, but your favorite framework decides to wait another three years before they switch over to layered styles? Many frameworks will likely still use <code>!important<\/code> more often than we&#8217;d like! With <code>!important<\/code> layers reversed, that\u2019s not ideal.<\/p>\n\n\n\n<p>Still, layers can still help us solve the problem. We just have to get clever about it. We decide what layers we want for our project, and that means we can add layers above <em>and<\/em> also below the framework layers we create.<\/p>\n\n\n\n<p>For now, though, we can use a lower layer to override <code>!important<\/code> styles from the framework, and a higher layer to override normal styles. Something like this:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer framework.important, framework.bootstrap, framework.local;\n@import url('bootstrap.css') layer(framework.bootstrap);\n\n@layer framework.local {\n  \/* most of our normal framework overrides can live here *\/\n}\n\n@layer framework.important {\n  \/* add !important styles in a lower layer *\/\n  \/* to override any !important framework styles *\/\n}<\/code><\/pre>\n\n\n\n<p>It still feels like a bit of a hack, but it helps move us in the right direction \u2014 towards a more structured cascade. Hopefully it\u2019s a temporary fix.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"designing-a-css-tool-or-framework\">Designing a CSS tool or framework<\/h4>\n\n\n<p>For anyone maintaining a CSS library, cascade layers can help with internal organization, and even become part of the developer API. By naming internal layers of a library, we can allow users of our framework to hook into those layers when customizing or overriding our provided styles.<\/p>\n\n\n\n<p>For example, Bootstrap could expose layers for their \u201creboot,\u201d \u201cgrid,\u201d and \u201cutilities\u201d \u2014 likely stacked in that order. Now a user can decide if they want to load those Bootstrap layers into different local layers:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@import url(bootstrap\/reboot.css) layer(reset); \/* reboot \u00bb reset.reboot *\/\n@import url(bootstrap\/grid.css) layer(layout); \/* grid \u00bb layout.grid *\/\n@import url(bootstrap\/utils.css) layer(override); \/* utils \u00bb override.utils *\/<\/code><\/pre>\n\n\n\n<p>Or the user might load them into a Bootstrap layer, with local layers interspersed:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer bs.reboot, bs.grid, bs.grid-overrides, bs.utils, bs.util-overrides;\n@import url('bootstrap-all.css') layer(bs);<\/code><\/pre>\n\n\n\n<p>It\u2019s also possible to hide internal layering from users, when desired, by grouping any private\/internal layers inside an anonymous (un-named) layer. Anonymous layers will get added to the layer order where they are encountered, but will not be exposed to users re-arranging or appending styles.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"i-just-want-this-one-property-to-be-more-important\">I just want this one property to be more <code>!important<\/code><\/h4>\n\n\n<p>Counter to some expectations, layers don\u2019t make it easy to quickly escalate a particular style so that it overrides another.<\/p>\n\n\n\n<p>If the majority of our styles are un-layered, then any new layer will be <em>de-prioritized<\/em> in relation to the default. We could do that to individual style blocks, but it would quickly become difficult to track.<\/p>\n\n\n\n<p>Layers are intended to be more foundational, not style-by-style, but establishing consistent patterns across a project. Ideally, if we\u2019ve set that up right, we get the correct result by moving our style to the appropriate (and pre-defined) layer.<\/p>\n\n\n\n<div class=\"wp-block-group ticss-27d72f02 has-white-color has-text-color has-background\" style=\"background:linear-gradient(135deg,rgb(31,31,31) 0%,rgb(84,88,93) 100%)\"><div class=\"wp-block-group__inner-container is-layout-flow wp-block-group-is-layout-flow\">\n<p>If the majority of our styles already fall into well-defined layers, we can always consider adding a new highest-power layer at the top of a given stack, or using un-layered styles to override the layers. We might even consider having a <code>debug<\/code> layer at the top of the stack, for doing exploratory work outside of production.<\/p>\n<\/div><\/div>\n\n\n\n<p>But adding new layers on-the-fly can defeat the organizational utility of this feature, and should be used carefully. It\u2019s best to ask: <em>Why should this style override the other?<\/em><\/p>\n\n\n\n<p>If the answer has to do with one <em>type of style<\/em> always overriding another type, layers are probably the right solution. That might be because we\u2019re overriding styles that come from a place we don\u2019t control, or because we\u2019re writing a utility, and it should move into our <code>utilities<\/code> layer. If the answer has to do with more targeted styles overriding less targeted styles, we might consider making the selectors reflect that specificity.<\/p>\n\n\n\n<p>Or, on rare occasions, we might even have styles that really are <em>important<\/em> \u2014 the feature simply doesn\u2019t work if you override this particular style. We might say adding <code>display: none<\/code> to the <code>[hidden]<\/code> attribute belongs in our lowest-priority reset, but should still be hard to override. In that case, <code>!important<\/code> really is the right tool for the job:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer reset {\n  [hidden] { display: none !important; }\n}<\/code><\/pre>\n\n\n<h4 class=\"wp-block-heading\" id=\"scoping-and-name-spacing-styles-nope\">Scoping and name-spacing styles? Nope!<\/h4>\n\n\n<p>Cascade layers are clearly an organizational tool, and one that \u2018captures\u2019 the impact of selectors, especially when they conflict. So it can be tempting at first glance to see them as a solution for managing scope or name-spacing.<\/p>\n\n\n\n<p>A common first-instinct is to create a layer for each component in a project \u2014 hoping that will ensure (for example) that <code>.post-title<\/code> is only applied inside a <code>.post<\/code>.<\/p>\n\n\n\n<p>But cascade conflicts are not the same as naming conflicts, and layers aren\u2019t particularly well designed for this type of scoped organization. Cascade layers don\u2019t constrain how selectors match or apply to the HTML, only how they cascade together. So unless we can be sure that component X <em>always<\/em> override component Y, individual component layers won\u2019t help much. Instead, we\u2019ll need to keep an eye on the <a href=\"https:\/\/www.w3.org\/TR\/css-cascade-6\/\" rel=\"noopener\">proposed <code>@scope<\/code> spec<\/a> that is being developed.<\/p>\n\n\n\n<p>It can be useful to think of layers and component-scopes instead as overlapping concerns:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large ticss-7bab32e4\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"711\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/layers-scope-01.png?resize=1024%2C711&#038;ssl=1\" alt=\"An illustration showing how CSS Cascade Layers can be organized by scope, such as buttons, cards, and login layers that fall into component, theme, and default scopes.\" class=\"wp-image-364132\" srcset=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/layers-scope-01.png?resize=1024%2C711&amp;ssl=1 1024w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/layers-scope-01.png?resize=300%2C208&amp;ssl=1 300w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/layers-scope-01.png?resize=768%2C533&amp;ssl=1 768w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/layers-scope-01.png?resize=1000%2C694&amp;ssl=1 1000w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/layers-scope-01.png?w=1164&amp;ssl=1 1164w\" sizes=\"(min-width: 735px) 864px, 96vw\" data-recalc-dims=\"1\" \/><\/figure>\n\n\n\n<p><dfn>Scopes<\/dfn> describe <em>what<\/em> we are styling, while layers describe <em>why<\/em> we are styling. We can also think of layers as representing <em>where the style comes from<\/em>, while scopes represent <em>what the style will attach to<\/em>.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"test-your-knowledge-which-style-wins\">Test your knowledge: Which style wins?<\/h3>\n\n\n<p>For each situation, assume this paragraph:<\/p>\n\n\n\n<pre rel=\"HTML\" class=\"wp-block-csstricks-code-block language-markup\" data-line=\"\"><code markup=\"tt\">&lt;p id=\"intro\">Hello, World!&lt;\/p><\/code><\/pre>\n\n\n<h4 class=\"wp-block-heading\" id=\"question-1\">Question 1<\/h4>\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer ultra-high-priority {\n  #intro {\n    color: red;\n  }\n}\n\np {\n  color: green;\n}<\/code><\/pre>\n\n\n\n<details >\n  <summary>\n          What color is the paragraph?      <\/summary>\n  \n\n<p>Despite the layer having a name that <em>sounds pretty important<\/em>, un-layered styles have a higher priority in the cascade. So the paragraph will be <code>green<\/code>.<\/p>\n\n\n<\/details>\n\n<h4 class=\"wp-block-heading\" id=\"question-2\">Question 2<\/h4>\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer ren, stimpy;\n\n@layer ren {\n  p { color: red !important; }\n}\n\np { color: green; }\n\n@layer stimpy {\n  p { color: blue !important; }\n}<\/code><\/pre>\n\n\n\n<details >\n  <summary>\n          What color is the paragraph?      <\/summary>\n  \n\n<p>Our normal layer order is established at the start \u2014 <code>ren<\/code> at the bottom, then <code>stimpy<\/code>, then (as always) un-layered styles at the top. But these styles aren\u2019t all <code>normal<\/code>, some of them are important. Right away, we can filter down to just the <code>!important<\/code> styles, and ignore the unimportant <code>green<\/code>. Remember that \u2018origins and importance\u2019 are the first step of the cascade, before we even take layering into account.<\/p>\n\n\n\n<p>That leaves us with two important styles, both in layers. Since our important layers are reversed, <code>ren<\/code> moves to the top, and <code>stimpy<\/code> to the bottom. The paragraph will be <code>red<\/code>.<\/p>\n\n\n<\/details>\n\n<h4 class=\"wp-block-heading\" id=\"question-3\">Question 3<\/h4>\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@layer Montagues, Capulets, Verona;\n\n@layer Montagues.Romeo { #intro { color: red; } }\n@layer Montagues.Benvolio { p { color: orange; } }\n\n@layer Capulets.Juliet { p { color: yellow; } }\n@layer Verona { * { color: blue; } }\n@layer Capulets.Tybalt { #intro { color: green; } }<\/code><\/pre>\n\n\n\n<details >\n  <summary>\n          What color is the paragraph?      <\/summary>\n  \n\n<p>All our styles are in the same origin and context, none are marked as important, and none of them are inline styles. We do have a broad range of selectors here, from a highly specific ID <code>#intro<\/code> to a zero specificity universal <code>*<\/code> selector. But layers are resolved before we take specificity into account, so we can ignore the selectors for now.<\/p>\n\n\n\n<p>The primary layer order is established up front, and then sub-layers are added internally. But sub-layers are sorted along with their parent layer \u2014 meaning all the <code>Montagues<\/code> will have lowest priority, followed by all the <code>Capulets<\/code>, and then <code>Verona<\/code> has final say in the layer order. So we can immediately filter down to just the <code>Verona<\/code> styles, which take precedence. Even though the <code>*<\/code> selector has zero specificity, it will win.<\/p>\n\n\n\n<p>Be careful about putting universal selectors in powerful layers!<\/p>\n\n\n<\/details>\n\n<h3 class=\"wp-block-heading\" id=\"debugging-layer-conflicts-in-browser-developer-tools\">Debugging layer conflicts in browser developer tools<\/h3>\n\n\n<p>Chrome, Safari, Firefox, and Edge browsers all have developer tools that allow you to inspect the styles being applied to a given element on the page. The styles panel of this element inspector will show applied selectors, sorted by their cascade priority (highest priority at the top), and then inherited styles below. Styles that are not being applied for any reason will generally be grayed out, or even crossed out \u2014 sometimes with additional information about <em>why<\/em> the style is not applied. This is the first place to look when debugging any aspect of the cascade, including layer conflicts.<\/p>\n\n\n\n<p>Safari Technology Preview and Firefox Nightly already show (and sort) cascade layers in this panel. This tooling is expected to role out in the stable versions at the same time as cascade layers. The layer of each selector is listed directly above the selector itself:<\/p>\n\n\n\n<div class=\"wp-block-columns is-layout-flex wp-container-core-columns-is-layout-2 wp-block-columns-is-layout-flex\">\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\" style=\"flex-basis:35%\">\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1040\" height=\"770\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232341_ScreenShot2022-02-03at11.35.41AM.jpg?resize=1040%2C770&#038;ssl=1\" alt=\"Showing CSS Cascade Layers in Safari DevTools.\" class=\"wp-image-363787\" srcset=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232341_ScreenShot2022-02-03at11.35.41AM.jpg?w=1040&amp;ssl=1 1040w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232341_ScreenShot2022-02-03at11.35.41AM.jpg?resize=300%2C222&amp;ssl=1 300w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232341_ScreenShot2022-02-03at11.35.41AM.jpg?resize=1024%2C758&amp;ssl=1 1024w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232341_ScreenShot2022-02-03at11.35.41AM.jpg?resize=768%2C569&amp;ssl=1 768w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232341_ScreenShot2022-02-03at11.35.41AM.jpg?resize=1000%2C740&amp;ssl=1 1000w\" sizes=\"(min-width: 735px) 864px, 96vw\" data-recalc-dims=\"1\" \/><figcaption>Safari<\/figcaption><\/figure>\n<\/div>\n\n\n\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\" style=\"flex-basis:65%\">\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1338\" height=\"608\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232366_ScreenShot2022-02-03at11.39.41AM.jpg?resize=1338%2C608&#038;ssl=1\" alt=\"Showing CSS Cascade Layers in FireFox DevTools.\" class=\"wp-image-363788\" srcset=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232366_ScreenShot2022-02-03at11.39.41AM.jpg?w=1338&amp;ssl=1 1338w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232366_ScreenShot2022-02-03at11.39.41AM.jpg?resize=300%2C136&amp;ssl=1 300w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232366_ScreenShot2022-02-03at11.39.41AM.jpg?resize=1024%2C465&amp;ssl=1 1024w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232366_ScreenShot2022-02-03at11.39.41AM.jpg?resize=768%2C349&amp;ssl=1 768w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/s_7269BD7CFF110C0C4578DCFE42CFC0B66C7F29AA3E50D4ABC024C679BD62AAD8_1643914232366_ScreenShot2022-02-03at11.39.41AM.jpg?resize=1000%2C454&amp;ssl=1 1000w\" sizes=\"(min-width: 735px) 864px, 96vw\" data-recalc-dims=\"1\" \/><figcaption>Firefox<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n<p>Chrome\/Edge are working on similar tools and expect to have them available in Canary (nightly) releases by the time cascade layers land in the stable release. We\u2019ll make updates here as those tools change and improve.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"browser-support-and-fallbacks\">Browser support and fallbacks<\/h3>\n\n<div class=\"caniuse\"><div class=\"caniuse-header\"><p>This browser support data is from <a href=\"http:\/\/caniuse.com\/#feat=css-cascade-layers\" rel=\"noopener\">Caniuse<\/a>, which has more detail. A number indicates that browser supports the feature at that version and up.<\/p><\/div><div class=\"caniuse-section\"><h4>Desktop<\/h4><table class=\"browser-support-table\"><thead><tr><th class=\"chrome\"><span>Chrome<\/span><\/th><th class=\"firefox\"><span>Firefox<\/span><\/th><th class=\"ie\"><span>IE<\/span><\/th><th class=\"edge\"><span>Edge<\/span><\/th><th class=\"safari\"><span>Safari<\/span><\/th><\/tr><\/thead><tbody><tr><td class=\"y yep\" title=\"Chrome - \"><span class=\"caniuse-agents-version version\">99<\/span><\/td><td class=\"y yep\" title=\"Firefox - \"><span class=\"caniuse-agents-version version\">97<\/span><\/td><td class=\"n nope\" title=\"IE - \"><span class=\"caniuse-agents-version version\">No<\/span><\/td><td class=\"y yep\" title=\"Edge - \"><span class=\"caniuse-agents-version version\">99<\/span><\/td><td class=\"y yep\" title=\"Safari - \"><span class=\"caniuse-agents-version version\">15.4<\/span><\/td><\/tr><\/table><\/div><div class=\"caniuse-section\"><h4>Mobile \/ Tablet<\/h4><table class=\"browser-support-table\"><thead><tr><th class=\"and_chr\"><span>Android Chrome<\/span><\/th><th class=\"and_ff\"><span>Android Firefox<\/span><\/th><th class=\"android\"><span>Android<\/span><\/th><th class=\"ios_saf\"><span>iOS Safari<\/span><\/th><\/tr><\/thead><tbody><tr><td class=\"y yep\" title=\"Android Chrome - \"><span class=\"caniuse-agents-version version\">123<\/span><\/td><td class=\"y yep\" title=\"Android Firefox - \"><span class=\"caniuse-agents-version version\">124<\/span><\/td><td class=\"y yep\" title=\"Android - \"><span class=\"caniuse-agents-version version\">123<\/span><\/td><td class=\"y yep\" title=\"iOS Safari - \"><span class=\"caniuse-agents-version version\">15.4<\/span><\/td><\/tr><\/table><\/div><\/div>\n\n\n\n<p>Since layers are intended as foundational building blocks of an entire CSS architecture, it is difficult to imagine building manual fallbacks in the same way you might for other CSS features. The fallbacks would likely involve duplicating large sections of code, with different selectors to manage cascade layering \u2014 or providing a much simpler fallback stylesheet.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"query-feature-support-using-supports\">Query feature support using <code>@supports<\/code><\/h4>\n\n\n<p>There is a <a href=\"https:\/\/css-tricks.com\/how-supports-works\/\"><code>@supports<\/code> feature in CSS<\/a> that will allow authors to test for support of <code>@layer<\/code> and other at-rules:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">@supports at-rule(@layer) {\n  \/* code applied for browsers with layer support *\/\n}\n\n@supports not at-rule(@layer) {\n  \/* fallback applied for browsers without layer support *\/\n}<\/code><\/pre>\n\n\n\n<p>However, it\u2019s also not clear when this query itself will be supported in browsers.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"assigning-layers-in-html-with-the-link-tag\">Assigning layers in HTML with the <code>&lt;link&gt;<\/code> tag<\/h4>\n\n\n<p>There is no official specification yet for a syntax to layer entire stylesheets from the html <code>&lt;link&gt;<\/code> tag, but there is a <a href=\"https:\/\/github.com\/whatwg\/html\/issues\/7540\" rel=\"noopener\">proposal being developed<\/a>. That proposal includes a new <code>layer<\/code> attribute which can be used to assign the styles to a named or anonymous layer:<\/p>\n\n\n\n<pre rel=\"HTML\" class=\"wp-block-csstricks-code-block language-markup\" data-line=\"\"><code markup=\"tt\">&lt;!-- styles imported into to the &lt;layer-name> layer -->\n&lt;link rel=\"stylesheet\" href=\"example.css\" layer=\"&lt;layer-name>\">\n\n&lt;!-- styles imported into to a new anonymous layer -->\n&lt;link rel=\"stylesheet\" href=\"example.css\" layer><\/code><\/pre>\n\n\n\n<p>However, old browsers without support for the <code>layer<\/code> attribute will ignore it completely, and continue to load the stylesheet without any layering. The results could be pretty unexpected. So the proposal also extends the existing <code>media<\/code> attribute, so that it allows feature support queries in a <code>support()<\/code> function.<\/p>\n\n\n\n<p>That would allow us to make layered links conditional, based on support for layering:<\/p>\n\n\n\n<pre rel=\"HTML\" class=\"wp-block-csstricks-code-block language-markup\" data-line=\"\"><code markup=\"tt\">&lt;link rel=\"stylesheet\" layer=\"bootstrap\" media=\"supports(at-rule(@layer))\" href=\"bootstrap.css\"><\/code><\/pre>\n\n\n<h4 class=\"wp-block-heading\" id=\"potential-polyfills-and-workarounds\">Potential polyfills and workarounds<\/h4>\n\n\n<p>The major browsers have all moved to an <a href=\"https:\/\/css-tricks.com\/evergreen-does-not-mean-immediately-available\/\">\u201cevergreen\u201d model<\/a> with updates pushed to users on a fairly short release cycle. Even Safari regularly releases new features in \u201cpatch\u201d updates between their more rare-seeming major versions.<\/p>\n\n\n\n<p>That means we can expect browser support for these features to ramp up very quickly. For many of us, it may be reasonable to start using layers in only a few months, without much concern for old browsers.<\/p>\n\n\n\n<p>For others, it may take longer to feel comfortable with the native browser support. There are many other ways to <a href=\"https:\/\/css-tricks.com\/dont-fight-the-cascade-control-it\/\">manage the cascade<\/a>, using selectors, <a href=\"https:\/\/css-tricks.com\/using-custom-property-stacks-to-tame-the-cascade\/\">custom properties<\/a>, and other tools. It\u2019s also theoretically possible to mimic (or polyfill) the basic behavior. There are people working on that polyfill, but it\u2019s not clear when that will be ready either.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"more-resources\">More resources<\/h3>\n\n\n<p>CSS Cascade Layers is still evolving but there is already a lot of resources, including documentation, articles, videos, and demos to help you get even more familiar with layers and how they work.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"reference\">Reference<\/h4>\n\n\n<ul><li><a href=\"https:\/\/www.w3.org\/TR\/css-cascade-5\/#layering\" rel=\"noopener\">Cascading &amp; Inheritance Level 5 Specification<\/a><\/li><li><a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/CSS\/@layer\" rel=\"noopener\">MDN Documentation<\/a><\/li><\/ul>\n\n\n<h4 class=\"wp-block-heading\" id=\"articles\">Articles<\/h4>\n\n\n<ul><li><a href=\"https:\/\/www.bram.us\/2021\/09\/15\/the-future-of-css-cascade-layers-css-at-layer\/\" rel=\"noopener\">The Future of CSS: Cascade Layers (CSS <code>@layer<\/code>)<\/a> by Bramus Van Damme<\/li><li><a href=\"https:\/\/www.smashingmagazine.com\/2022\/01\/introduction-css-cascade-layers\/\" rel=\"noopener\">Getting Started With CSS Cascade Layers<\/a> by Stephanie Eckles, <em>Smashing Magazine<\/em><\/li><li><a href=\"https:\/\/developer.chrome.com\/blog\/cascade-layers\/\" rel=\"noopener\">Cascade layers are coming to your browser<\/a> by Una Kravets, <em>Chrome Developers<\/em><\/li><\/ul>\n\n\n<h4 class=\"wp-block-heading\" id=\"videos\">Videos<\/h4>\n\n\n<ul><li><a href=\"https:\/\/youtu.be\/dS123IXPcJ0\" rel=\"noopener\">How does CSS !important actually work?<\/a> by Una Kravets<\/li><li><a href=\"https:\/\/youtu.be\/ilrPpSQJb3U\" rel=\"noopener\">An overview of the new @layer and layer() CSS primitives<\/a> by Una Kravets<\/li><li><a href=\"https:\/\/www.youtube.com\/watch?v=2wSckPwaC_A\" rel=\"noopener\">CSS Revert &amp; Revert-Layer Keywords<\/a> by Una Kravets<\/li><\/ul>\n\n\n<h4 class=\"wp-block-heading\" id=\"demos\">Demos<\/h4>\n\n\n<ul><li><a href=\"https:\/\/codepen.io\/collection\/BNjmma\" rel=\"noopener\">Layers CodePen collection<\/a><\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"<p>This is your complete guide to CSS cascade layers, a CSS feature that allows us to define explicit contained layers of specificity, so that we have full control over which styles take priority in a project without relying on specificity hacks or !important. This guide is intended to help you fully understand what cascade layers [&hellip;]<\/p>\n","protected":false},"author":245622,"featured_media":363814,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"c2c_always_allow_admin_comments":false,"footnotes":"","jetpack_publicize_message":"Here ya go: everything @TerribleMia knows about CSS Cascade Layers in a guide only she could write \u2014 from syntax and establishing layer order to debugging and playing friendly with third-party frameworks!","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[19012],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/cascade-layers-guide.png?fit=1200%2C600&ssl=1","jetpack-related-posts":[{"id":352140,"url":"https:\/\/css-tricks.com\/cascade-layers\/","url_meta":{"origin":363766,"position":0},"title":"Cascade Layers","date":"September 21, 2021","format":false,"excerpt":"There is a new thing coming in CSS: @layer. This comes from Miriam Suzanne, who is really on a tear with influencing important new CSS stuff. I've been hearing about all this, but then all a sudden it just dropped in experimental browsers. Leave it to Bramus to really dig\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2018\/11\/cssstacks.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":372576,"url":"https:\/\/css-tricks.com\/using-css-cascade-layers-to-manage-custom-styles-in-a-tailwind-project\/","url_meta":{"origin":363766,"position":1},"title":"Using CSS Cascade Layers to Manage Custom Styles in a Tailwind Project","date":"August 24, 2022","format":false,"excerpt":"If a utility class only does one thing, chances are you don\u2019t want it to be overridden by any styles coming from elsewhere. One approach is to use !important to be 100% certain the style will be applied, regardless of specificity conflicts. The Tailwind config file has an !important option\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/08\/tailwind-layers.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":359886,"url":"https:\/\/css-tricks.com\/dont-fight-the-cascade-control-it\/","url_meta":{"origin":363766,"position":2},"title":"Don&#8217;t Fight the Cascade, Control It!","date":"January 10, 2022","format":false,"excerpt":"If you\u2019re disciplined and make use of the inheritance that the CSS cascade provides, you\u2019ll end up writing less CSS. But because our styles often comes from all kinds of sources \u2014 and can be a pain to structure and maintain\u2014the cascade can be a source of frustration, and the\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/12\/stephen-leonardi-LfDwhVBfqEk-unsplash-scaled.jpg?fit=1200%2C796&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":364152,"url":"https:\/\/css-tricks.com\/manuel-matuzovics-css-specificity-demo\/","url_meta":{"origin":363766,"position":3},"title":"Manuel Matuzovic&#8217;s CSS Specificity Demo","date":"February 25, 2022","format":false,"excerpt":"If you're looking for a primer on CSS specificity, we've got that. And if you're trying to get ahead of the game, you should be aware of CSS Cascade Layers as well. One of the ways to help get a grasp of CSS specificity is thinking terms of \"what beats\u2026","rel":"","context":"In &quot;Link&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2018\/12\/css-audit-specificity-graph.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":374401,"url":"https:\/\/css-tricks.com\/some-things-i-took-away-from-an-event-apart-2022-in-denver\/","url_meta":{"origin":363766,"position":4},"title":"Some Things I Took Away From An Event Apart 2022 in Denver","date":"October 13, 2022","format":false,"excerpt":"An Event Apart 2022 Denver wrapped up yesterday. And while I was unable to make it to all three days this time, I did catch yesterday's action \u2014 and it was awesome. I'm not very social or outgoing, but this was the first conference I've been to in at least\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/10\/an-event-apart-denver-2022.png?fit=1200%2C559&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":312969,"url":"https:\/\/css-tricks.com\/using-custom-property-stacks-to-tame-the-cascade\/","url_meta":{"origin":363766,"position":5},"title":"Using Custom Property &#8220;Stacks&#8221; to Tame the Cascade","date":"June 22, 2020","format":false,"excerpt":"Since the inception of CSS in 1994, the cascade and inheritance have defined how we design on the web. Both are powerful features but, as authors, we've had very little control over how they interact. Selector specificity and source order provide some minimal \"layering\" control, without a lot of nuance\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/06\/custom-property-stacks.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"featured_media_src_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/02\/cascade-layers-guide.png?fit=1024%2C512&ssl=1","_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/363766"}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/users\/245622"}],"replies":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/comments?post=363766"}],"version-history":[{"count":9,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/363766\/revisions"}],"predecessor-version":[{"id":374589,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/363766\/revisions\/374589"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media\/363814"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=363766"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/categories?post=363766"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/tags?post=363766"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}