{"id":312969,"date":"2020-06-22T07:47:49","date_gmt":"2020-06-22T14:47:49","guid":{"rendered":"https:\/\/css-tricks.com\/?p=312969"},"modified":"2022-05-23T10:40:35","modified_gmt":"2022-05-23T17:40:35","slug":"using-custom-property-stacks-to-tame-the-cascade","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/using-custom-property-stacks-to-tame-the-cascade\/","title":{"rendered":"Using Custom Property &#8220;Stacks&#8221; to Tame the Cascade"},"content":{"rendered":"\n<p>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&#8217;ve had very little control over how they interact. Selector specificity and source order provide some minimal &#8220;layering&#8221; control, without a lot of nuance &#8212; and inheritance requires an <em>unbroken lineage<\/em>. <strong>Now, CSS Custom Properties allow us to manage and control both cascade and inheritance in new ways.<\/strong><\/p>\n\n\n\n<p>I want to show you how I&#8217;ve used Custom Property &#8220;stacks&#8221; to solve some of the common issues people face in the cascade: from scoped component styles, to more explicit layering of intents.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"a-quick-intro-to-custom-properties\">A quick intro to Custom Properties<\/h3>\n\n\n<p>The same way browsers have defined new properties using a vendor prefix like <code>-webkit-<\/code> or <code>-moz-<\/code>, we can define our own Custom Properties with an \u201cempty\u201d <code>--<\/code> prefix. Like variables in Sass or JavaScript, we can use them to name, store, and retrieve values &#8212; but like other properties in CSS, they <strong>cascade<\/strong> and <strong>inherit<\/strong> with the DOM.<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* Define a custom property *\/\nhtml {\n  --brand-color: rebeccapurple;\n}<\/code><\/pre>\n\n\n\n<p>In order to access those captured values, we use the <code>var()<\/code> function. It has two parts: first the name of our custom property, and then a fallback in case that property is undefined:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">button {\n  \/* use the --brand-color if available, or fall back to deeppink *\/\n  background: var(--brand-color, deeppink);\n}<\/code><\/pre>\n\n\n\n<p>This is not a support fallback for old browsers. If a browser doesn\u2019t understand custom properties, it will ignore the entire <code>var()<\/code> declaration. Instead, this is a built-in way of handling undefined variables, similar to a font stack defining fallback font families when one is unavailable. If we don&#8217;t provide a fallback, the default is <code>unset<\/code>.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"building-variable-stacks\">Building variable &#8220;stacks&#8221;<\/h3>\n\n\n<p>This ability to define a fallback is similar to &#8220;font stacks&#8221; used on the <code>font-family<\/code> property. If the first family is unavailable, the second will be used, and so on. The <code>var()<\/code> function only accepts a single fallback, but we can nest <code>var()<\/code> functions to create custom-property fallback &#8220;stacks&#8221; of any size:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">button {\n  \/* try Consolas, then Menlo, then Monaco, and finally monospace *\/\n  font-family: Consolas, Menlo, Monaco, monospace;\n\n  \/* try --state, then --button-color, then --brand-color, and finally deeppink *\/\n  background: var(--state, var(--button-color, var(--brand-color, deeppink)));\n}<\/code><\/pre>\n\n\n\n<p>If that nested syntax for stacked properties looks bulky, you can use a pre-processor like Sass to make it more compact.<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_GRpmOjr\" src=\"\/\/codepen.io\/anon\/embed\/GRpmOjr?height=450&amp;theme-id=1&amp;slug-hash=GRpmOjr&amp;default-tab=result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed GRpmOjr\" title=\"CodePen Embed GRpmOjr\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n\n<p>That single-fallback limitation is required to support fallbacks with a comma inside them &#8212; like font stacks or layered background images:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">html {\n  \/* The fallback value is \"Helvetica, Arial, sans-serif\" *\/\n  font-family: var(--my-font, Helvetica, Arial, sans-serif);\n}<\/code><\/pre>\n\n\n<h3 class=\"wp-block-heading\" id=\"defining-scope\">Defining &#8220;scope&#8221;<\/h3>\n\n\n<p>CSS selectors allow us to drill down into the HTML DOM tree, and style elements anywhere on the page, or elements in a particular nested context.<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">\/* all links *\/\na { color: slateblue; }\n\n\/* only links inside a section *\/\nsection a { color: rebeccapurple; }\n\n\/* only links inside an article *\/\narticle a { color: deeppink; }<\/code><\/pre>\n\n\n\n<p>That&#8217;s useful, but it doesn&#8217;t capture the reality of &#8220;modular&#8221; object-oriented or component-driven styles. We might have multiple articles and asides, nested in various configurations. We need a way to clarify which context, or <strong>scope<\/strong>, should take precedence when they overlap.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"proximity-scopes\">Proximity scopes<\/h4>\n\n\n<p>Let&#8217;s say we have a <code>.light<\/code> theme and a <code>.dark<\/code> theme. We can use those classes on the root <code>&lt;html&gt;<\/code> element to define a page-wide default, but we can also apply them to specific components, nested in various ways:<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_ExPYEVQ\" src=\"\/\/codepen.io\/anon\/embed\/ExPYEVQ?height=450&amp;theme-id=1&amp;slug-hash=ExPYEVQ&amp;default-tab=result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed ExPYEVQ\" title=\"CodePen Embed ExPYEVQ\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n\n<p>Each time we apply one of our color-mode classes, the <code>background<\/code> and <code>color<\/code> properties are reset, then inherited by nested headings and paragraphs. In our main context, colors inherit from the <code>.light<\/code> class, while the nested heading and paragraph inherit from the <code>.dark<\/code> class. Inheritance is based on direct lineage, so the nearest ancestor with a defined value will take precedence. We call that <strong>proximity<\/strong>.<\/p>\n\n\n\n<p>Proximity matters for inheritance, but it has no impact on selectors, which rely on specificity. That becomes a problem if we want to style something <em>inside<\/em> the dark or light containers.<\/p>\n\n\n\n<p>Here I&#8217;ve attempted to define both light and dark button variants. Light mode buttons should be <code>rebeccapurple<\/code> with <code>white<\/code> text so they stand out, and dark mode buttons should be <code>plum<\/code> with <code>black<\/code> text. We&#8217;re selecting the buttons directly based on a light and dark context, but it doesn&#8217;t work:<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_NWxKYRN\" src=\"\/\/codepen.io\/anon\/embed\/NWxKYRN?height=450&amp;theme-id=1&amp;slug-hash=NWxKYRN&amp;default-tab=result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed NWxKYRN\" title=\"CodePen Embed NWxKYRN\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n\n<p>Some of the buttons are in both contexts, with both <code>.light<\/code> and <code>.dark<\/code> ancestors. What we want in that case is for the closest theme to take over (inheritance <em>proximity<\/em> behavior), but what we get instead is the second selector overriding the first (cascade behavior). Since the two selectors have the same specificity, source order determines the winner.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"custom-properties-and-proximity\">Custom Properties and proximity<\/h3>\n\n\n<p>What we need here is a way to <em>inherit<\/em> these properties from the theme, but only apply them to specific children. Custom Properties make that possible! We can define values on the light and dark containers, while only using their inherited values on nested elements, like our buttons.<\/p>\n\n\n\n<p>We&#8217;ll start by setting up the buttons to use custom properties, with a fallback &#8220;default&#8221; value, in case those properties are undefined:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">button {\n  background: var(--btn-color, rebeccapurple);\n  color: var(--btn-contrast, white);\n}<\/code><\/pre>\n\n\n\n<p>Now we can set those values based on context, and they will <em>scope<\/em> to the appropriate ancestor based on proximity and inheritance:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">.dark {\n  --btn-color: plum;\n  --btn-contrast: black;\n}\n\n.light {\n  --btn-color: rebeccapurple;\n  --btn-contrast: white;\n}<\/code><\/pre>\n\n\n\n<p>As an added bonus, we&#8217;re using less code overall, and one unified <code>button<\/code> definition:<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_QWyLrdr\" src=\"\/\/codepen.io\/anon\/embed\/QWyLrdr?height=450&amp;theme-id=1&amp;slug-hash=QWyLrdr&amp;default-tab=result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed QWyLrdr\" title=\"CodePen Embed QWyLrdr\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n\n<p>I think of this as creating an API of available parameters for the button component. <a href=\"https:\/\/www.sarasoueidan.com\/blog\/style-settings-with-css-variables\/\" rel=\"noopener\">Sara Soueidan<\/a> and <a href=\"https:\/\/increment.com\/frontend\/a-users-guide-to-css-variables\/\" rel=\"noopener\">Lea Verou<\/a> have both covered this well in recent articles.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"component-ownership\">Component ownership<\/h3>\n\n\n<p>Sometimes proximity isn&#8217;t enough to define scope. When JavaScript frameworks generate &#8220;scoped styles&#8221; they are establishing specific object-element <strong>ownership<\/strong>. A &#8220;tab layout&#8221; component <em>owns<\/em> the tabs themselves, but not the content behind each tab. This is also what the BEM convention attempts to capture in complex <code>.block__element<\/code> class names.<\/p>\n\n\n\n<p>Nicole Sullivan <a href=\"http:\/\/www.stubbornella.org\/content\/2011\/10\/08\/scope-donuts\/\" rel=\"noopener\">coined the term &#8220;donut scope&#8221;<\/a> to talk about this problem back in 2011. While I&#8217;m sure she has more recent thoughts on the issue, the fundamental problem hasn&#8217;t changed. Selectors and specificity are great for describing how we build detailed styles over top of broad patterns, but they don&#8217;t convey a clear sense of ownership.<\/p>\n\n\n\n<p>We can use custom property stacks to help solve this problem. We&#8217;ll start by creating &#8220;global&#8221; properties on the <code>&lt;html&gt;<\/code> element that are for our default colors:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">html {\n  --background--global: white;\n  --color--global: black;\n  --btn-color--global: rebeccapurple;\n  --btn-contrast--global: white;\n}<\/code><\/pre>\n\n\n\n<p>That default global theme is now available anywhere we want to refer to it. We&#8217;ll do that with a <code>data-theme<\/code> attribute that applies our foreground and background colors. We want the global values to provide a default fallback, but we also want the option to override with a specific theme. That&#8217;s where &#8220;stacks&#8221; come in:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">[data-theme] {\n  \/* If there's no component value, use the global value *\/\n  background: var(--background--component, var(--background--global));\n  color: var(--color--component, var(--color--global));\n}<\/code><\/pre>\n\n\n\n<p>Now we can define an inverted component by setting the <code>*--component<\/code> properties as a reverse of the global properties:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">[data-theme='invert'] {\n  --background--component: var(--color--global);\n  --color--component: var(--background--global);\n}<\/code><\/pre>\n\n\n\n<p>But we don&#8217;t want those settings to inherit beyond the donut of ownership, so we reset those values to <code>initial<\/code> (undefined) on every theme. We\u2019ll want to do this at a lower specificity, or earlier in the source order, so it provides a default that each theme can override:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">[data-theme] {\n  --background--component: initial;\n  --color--component: initial;\n}<\/code><\/pre>\n\n\n\n<p>The <code>initial<\/code> keyword has a special meaning when used on custom properties, reverting them to a <a href=\"https:\/\/drafts.csswg.org\/css-variables\/#guaranteed-invalid-value\" rel=\"noopener\">Guaranteed-Invalid<\/a> state. That means rather than being passed along to set <code>background: initial<\/code> or <code>color: initial<\/code>, the custom property becomes <code>undefined<\/code>, and we fallback to the next value in our stack, the global settings.<\/p>\n\n\n\n<p>We can do the same thing with our buttons, and then make sure to apply <code>data-theme<\/code> to each component. If no specific theme is given, each component will default to the global theme:<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_VweaPGp\" src=\"\/\/codepen.io\/anon\/embed\/VweaPGp?height=450&amp;theme-id=1&amp;slug-hash=VweaPGp&amp;default-tab=result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed VweaPGp\" title=\"CodePen Embed VweaPGp\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n<h3 class=\"wp-block-heading\" id=\"defining-origins\">Defining &#8220;origins&#8221;<\/h3>\n\n\n<p>The CSS cascade is a series of filtering layers used to determine what value should take precedence when multiple values are defined on the same property. We most often interact with the <strong>specificity<\/strong> layers, or the final layering based on source-order &#8212; but the first layer of cascade is the &#8220;origin&#8221; of a style. The <strong>origin<\/strong> describes where a style came from &#8212; often the browser (defaults), the user (preferences), or the author (that&#8217;s us).<\/p>\n\n\n\n<p>By default, author styles override user preferences, which override browser defaults. That changes when anyone applies `!important` to a style, and the origins reverse: browser `!important` styles have the highest origin, then important user preferences, then our author important styles, above all the normal layers. There are <a href=\"https:\/\/www.w3.org\/TR\/css-cascade-3\/#cascading-origins\" rel=\"noopener\">a few additional origins<\/a>, but we won&#8217;t go into them here.<\/p>\n\n\n\n<p>When we create custom property &#8220;stacks,&#8221; we&#8217;re building a very similar behavior. If we wanted to represent existing origins as a stack of custom properties, it would look something like this:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">.origins-as-custom-properties {\n  color: var(--browser-important, var(--user-important, var(--author-important, var(--author, var(--user, var(--browser))))));\n}<\/code><\/pre>\n\n\n\n<p>Those layers already exist, so there&#8217;s no reason to recreate them. But we&#8217;re doing something very similar when we layer our &#8220;global&#8221; and &#8220;component&#8221; styles above &#8212; creating a &#8220;component&#8221; origin layer that overrides our &#8220;global&#8221; layer. That same approach can be used to solve various layering issues in CSS, which can&#8217;t always be described by specificity:<\/p>\n\n\n\n<ul><li>Override \u00bb Component \u00bb Theme \u00bb Default<\/li><li>Theme \u00bb Design system or framework<\/li><li>State \u00bb Type \u00bb Default<\/li><\/ul>\n\n\n\n<p>Let&#8217;s look at some buttons again. We&#8217;ll need a default button style, a disabled state, and various button &#8220;types,&#8221; like <code>danger<\/code>, <code>primary<\/code> and <code>secondary<\/code>. We wan&#8217;t the <code>disabled<\/code> state to always override the type variations, but selectors don&#8217;t capture that distinction:<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_abdoYLa\" src=\"\/\/codepen.io\/anon\/embed\/abdoYLa?height=450&amp;theme-id=1&amp;slug-hash=abdoYLa&amp;default-tab=result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed abdoYLa\" title=\"CodePen Embed abdoYLa\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n\n<p>But we can define a stack that provides both &#8220;type&#8221; and &#8220;state&#8221; layers in the order that we want them prioritized:<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">button {\n  background: var(--btn-state, var(--btn-type, var(--btn-default)));\n}<\/code><\/pre>\n\n\n\n<p>Now when we set both variables, the state will always take precedence:<\/p>\n\n\n\n<div class=\"wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper\"><iframe id=\"cp_embed_abdNWwa\" src=\"\/\/codepen.io\/anon\/embed\/abdNWwa?height=450&amp;theme-id=1&amp;slug-hash=abdNWwa&amp;default-tab=result\" height=\"450\" scrolling=\"no\" frameborder=\"0\" allowfullscreen allowpaymentrequest name=\"CodePen Embed abdNWwa\" title=\"CodePen Embed abdNWwa\" class=\"cp_embed_iframe\" style=\"width:100%;overflow:hidden\">CodePen Embed Fallback<\/iframe><\/div>\n\n\n\n<p>I&#8217;ve used this technique to create a <a href=\"https:\/\/cascading-colors.netlify.com\/\" rel=\"noopener\">Cascading Colors<\/a> framework that allows custom theming based on layering:<\/p>\n\n\n\n<ul><li>Pre-defined theme attributes in the HTML<\/li><li>User color preferences<\/li><li>Light and dark modes<\/li><li>Global theme defaults<\/li><\/ul>\n\n\n<h3 class=\"wp-block-heading\" id=\"mix-and-match\">Mix and match<\/h3>\n\n\n<p>These approaches can be <a href=\"https:\/\/codepen.io\/mirisuzanne\/pen\/KKdWXGo?editors=1100\" rel=\"noopener\">taken to an extreme<\/a>, but most day-to-day use-cases can be handled with two or three values in a stack, often using a combination of the techniques above:<\/p>\n\n\n\n<ul><li>A variable stack to define the layers<\/li><li>Inheritance to set them based on proximity and scope<\/li><li>Careful application of the `initial` value to remove nested elements from a scope<\/li><\/ul>\n\n\n\n<hr class=\"wp-block-separator\"\/>\n\n\n\n<p>We&#8217;ve been using these custom property &#8220;stacks&#8221; on our projects at OddBird. We&#8217;re still discovering as we go, but they&#8217;ve already been helpful in solving problems that were difficult using only selectors and specificity. With custom properties, we don&#8217;t have to fight the cascade or inheritance. We can capture and leverage them, as-intended, with more control over how they should apply in each instance. To me, that&#8217;s a big win for CSS \u2014 especially when developing style frameworks, tools, and <em>systems<\/em>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8217;ve had very little control over how they interact. Selector specificity and source order provide some minimal &#8220;layering&#8221; control, without a lot of nuance &#8212; and inheritance requires an [&hellip;]<\/p>\n","protected":false},"author":245622,"featured_media":312975,"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":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[896,1036,17249],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/06\/custom-property-stacks.png?fit=1200%2C600&ssl=1","jetpack-related-posts":[{"id":275709,"url":"https:\/\/css-tricks.com\/a-tale-of-two-buttons\/","url_meta":{"origin":312969,"position":0},"title":"A Tale of Two Buttons","date":"August 27, 2018","format":false,"excerpt":"I enjoy front-end developer thought progression articles like this one by James Nash. Say you have a button which needs to work in \"normal\" conditions (light backgrounds) and one with reverse-colors for going on dark backgrounds. Do you have a modifier class on the button itself? How about on the\u2026","rel":"","context":"In &quot;Link&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2018\/08\/two-buttons.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":264665,"url":"https:\/\/css-tricks.com\/latest-ways-deal-cascade-inheritance-specificity\/","url_meta":{"origin":312969,"position":1},"title":"The latest ways to deal with the cascade, inheritance and specificity","date":"January 10, 2018","format":false,"excerpt":"The cascade is such an intrinsic part of CSS that they put it right there in the name. If you\u2019ve ever needed to use !important to affect specificity in the cascade, you\u2019ll know that it can be a tricky thing to deal with. In the early days of CSS, it\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":278596,"url":"https:\/\/css-tricks.com\/the-c-in-css-the-cascade\/","url_meta":{"origin":312969,"position":2},"title":"The &#8220;C&#8221; in CSS: The Cascade","date":"November 13, 2018","format":false,"excerpt":"Following up from Geoff\u2019s intro article on The Second \"S\" in CSS, let\u2019s now move the spotlight to the \"C\" in CSS \u2014 what we call the Cascade. It\u2019s where things start to get messy, and even confusing at times. Have you ever written a CSS property and the value\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2018\/11\/cascade-bubbles.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":246274,"url":"https:\/\/css-tricks.com\/difference-between-types-of-css-variables\/","url_meta":{"origin":312969,"position":3},"title":"What is the difference between CSS variables and preprocessor variables?","date":"October 25, 2016","format":false,"excerpt":"Variables are one of the major reasons CSS preprocessors exist at all. The ability to set a variable for something like a color, use that variable throughout the CSS you write, and know that it will be consistent, DRY, and easy to change is useful. You can use native CSS\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":254692,"url":"https:\/\/css-tricks.com\/making-custom-properties-css-variables-dynamic\/","url_meta":{"origin":312969,"position":4},"title":"Making Custom Properties (CSS Variables) More Dynamic","date":"May 10, 2017","format":false,"excerpt":"CSS Custom Properties (perhaps more easily understood as CSS variables) provide us ways to make code more concise, as well as introduce new ways to work with CSS that were not possible before. They can do what preprocessor variables can\u2026 but also a lot more. Whether you have been a\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/05\/hexagons-orange.png?fit=1142%2C602&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":296424,"url":"https:\/\/css-tricks.com\/patterns-for-practical-css-custom-properties-use\/","url_meta":{"origin":312969,"position":5},"title":"Patterns for Practical CSS Custom Properties Use","date":"October 9, 2019","format":false,"excerpt":"I've been playing around with CSS Custom Properties to discover their power since browser support is finally at a place where we can use them in our production code. I\u2019ve been using them in a number different ways and I\u2019d love for you to get as excited about them as\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/09\/custom-properties-code.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/312969"}],"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=312969"}],"version-history":[{"count":8,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/312969\/revisions"}],"predecessor-version":[{"id":366027,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/312969\/revisions\/366027"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media\/312975"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=312969"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/categories?post=312969"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/tags?post=312969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}