Organizing Design System Component Patterns With CSS Cascade Layers-CSS Tutorial-php.cn

Organizing Design System Component Patterns With CSS Cascade Layers

This article discusses how to use the CSS cascade layer to improve the customizability, efficiency, ease of use and ease of understanding of components.

I am passionate about code organization and find that the cascade is an excellent way to organize your code explicitly because it follows the cascade's read order directly. Even better, in addition to helping with "top-level" organizations, cascades can also be nested, allowing us to write more precise styles based on cascades.

The only downside is your imagination – nothing can stop us from over-designing CSS. To be clear, you'll likely think that what I'm about to show is an overdesign. But I think I've found a balance point, kept it simple and organized, and am happy to share my findings.

Composition of CSS component mode

Let's use buttons as an example to explore the pattern of writing components using CSS. Buttons are one of the most popular components in almost every component library. There is a reason for this popularity, as buttons can be used in a variety of use cases including:

Perform an action, such as opening a drawer,
Navigate to different parts of the UI, and
Keep some state, such as focus or hover.

And the buttons come in many different marking forms, such as <button></button>, input[type="button"] and <a></a>. If you believe, there are even more ways to make buttons.

Most importantly, different buttons perform different functions and are usually styled accordingly so that the buttons of one operation are distinguished from the buttons of another operation. Buttons also respond to state changes, such as when they hover, move, and focus. If you have ever written CSS using BEM syntax, we can think along a similar idea in the context of the cascade layer.

Okay, let's write some code now. Specifically, let's create several different types of buttons. We will start with a

<code>.button {}
.button-primary {}
.button-secondary {}
.button-warning {}
/* etc. */</code>

Copy after login

class that we can set to any element we want to set as a button! We already know that buttons come in many different tag forms, so the common

class is the most reusable and extensible way to choose one or all of these buttons. .button .button

Using cascades

<code>.button {
  /* 所有按钮的通用样式 */
}</code>

Copy after login

Here, we can insert our first cascade layer! Remember, the reason we want the cascade layer first is that it allows us to set the read order of the CSS cascade when evaluating the style. We can tell CSS to evaluate one layer first, then another layer, then another layer - all in the order we want. This is an incredible feature that gives us super powers to control which styles the browser applies to "win".

We name this layer components because the button is a component. The reason I like the name is that it is generic enough to support other components we will add in the future when deciding to extend the design system. It scales with us while maintaining a good separation of concern from other styles we write in the future that may not be specific to components.

<code>.button {}
.button-primary {}
.button-secondary {}
.button-warning {}
/* etc. */</code>

Copy after login

Nested cascades

Where things get a little weird is here. Did you know that you can nest cascade layers inside class ? This is a total thing. So, looking at this, we can introduce a new layer inside the class that is already located within its own layer. This is what I mean: .button In the end, this is how the browser interprets the inner layer:

<code>.button {
  /* 所有按钮的通用样式 */
}</code>

Copy after login

This post is not just about nested styles, so I just want to say that when you do, your mileage may vary. Check out Andy Bell's recent article on using nested styles with caution.

<code>/* 组件顶级层 */
@layer components {
  .button {
    /* 所有按钮的通用样式 */
  }
}</code>

Copy after login

Style structure

So far, we have established a

class within a cascade layer designed to accommodate any type of components in our design system. Inside this

is another cascade layer that is used to select different types of buttons we may encounter in the tag. We've discussed before that the buttons are

, .button or .button, which is how we choose to style each type individually. <button></button> <input>We can use the <a></a> pseudo-selector function, which is similar to saying: "If this

is a :is() an .button element, then these styles are applied." <a></a>Define the default button style

<code>/* 组件顶级层 */
@layer components {

  .button {
    /* 组件元素层 */
    @layer elements {
      /* 样式 */
    }
  }
}</code>

Copy after login

I will fill our code with a universal style that works for all buttons. These styles are located at the top of the element layer, so they will be applied to any and all buttons regardless of the marking. They can be considered as the default button style.

Define button status style

<code>@layer components {
  @layer elements {
    .button {
      /* 按钮样式... */
    }
  }
}</code>

Copy after login

What should users do when they interact with the default button? These are the different states that buttons may take when the user interacts with them, and we need to style them accordingly.

I will create a new cascaded sublayer directly below the element sublayer, creatively called "states" (state):

Pause and think about it here. What states should we target? What do we want to change for each of these states?

Some states may share similar property changes, such as :hover and :focus with the same background color. Fortunately, CSS provides us with tools to solve such problems, using the :where() function to group property changes based on state. Why use :where() instead of :is()? :where() has zero specificity, which means it is easier to cover than , taking the specificity of the element with the highest specificity score in its parameters. Keeping specificity low is a virtue when writing scalable, maintainable CSS. :is() :is()

But how do we update the style of the button in a

<code>.button {}
.button-primary {}
.button-secondary {}
.button-warning {}
/* etc. */</code>

Copy after login

meaningful way? I mean, how do we make sure the button looks like hover or focus? We just need to add a new background color to it, but ideally the color should be related to the

set in the element layer. So let's refactor it a little. Previously, I set the background-color of the

element to

. I want to reuse the color, so it's better to convert it to a CSS variable so we can update it at once and make it apply everywhere. Depend on variables is another advantage of writing scalable and maintainable CSS. .button background-colorI will create a new variable called darkslateblue which is initially set to

and then set it to the default button style:

--button-background-color darkslateblue Now that we have stored the colors in variables, we can set the same variable to the hover and focus state of the button in other layers, converting

to a lighter color using the relatively new

<code>.button {
  /* 所有按钮的通用样式 */
}</code>

Copy after login

function, when the button is hovered or focused.

color-mix()Back to our state layer! We first blend the colors in a new CSS variable called darkslateblue:

--state-background-color We can then apply that color by updating the

attribute.

<code>/* 组件顶级层 */
@layer components {
  .button {
    /* 所有按钮的通用样式 */
  }
}</code>

Copy after login

background-colorDefine the modified button style

<code>/* 组件顶级层 */
@layer components {

  .button {
    /* 组件元素层 */
    @layer elements {
      /* 样式 */
    }
  }
}</code>

Copy after login

In addition to elements and state layers, you may also be looking for some type of changes in components, such as modifiers. This is because not all buttons will be like your default button. You may want a button with a green background color for users to confirm decisions. Or you might want a red button that indicates danger when clicked. So we can take the existing default button styles and modify them for these specific use cases.

If we consider the order of cascades—always flowing from top to bottom—we do not want the modified style to affect the styles in the state layer we just made. So let's add a new modifier layer between the element and the state:

Similar to how we handle state, we can now update the

variable for each button modifier. Of course, we can modify the style further, but we keep it fairly simple to demonstrate how this system works.

<code>@layer components {
  @layer elements {
    .button {
      /* 按钮样式... */
    }
  }
}</code>

Copy after login

We will create a new class that changes the default button's background-color from darkslateblue to darkgreen. Again, we can rely on the :is() selector because in this case we need increased specificity. This way, we can override the default button style with the modifier class. We call this class .success (green is the color of "success") and provide it to :is():

<code>.button {}
.button-primary {}
.button-secondary {}
.button-warning {}
/* etc. */</code>

Copy after login

If we add the .success class to one of our buttons, it will become darkgreen instead of darkslateblue, which is exactly what we want. Since we have done some color-mix() operations in the state layer, we will automatically inherit these hover and focus styles, which means that darkgreen will become shallow in these states.

<code>.button {
  /* 所有按钮的通用样式 */
}</code>

Copy after login

Integrate everything together

We can refactor any CSS attributes that need to be modified into CSS custom attributes, which provides us with a lot of customization space.

<code>/* 组件顶级层 */
@layer components {
  .button {
    /* 所有按钮的通用样式 */
  }
}</code>

Copy after login

Please note: Take a closer look at the demo and see how I adjusted the button background using light-dark()—and read Sara Joy's "Come to the light-dark() side" to get a full view of how it works!

What do you think? Will you use it to organize your style? For a small project with few components, creating a cascade system can be overly . But even a little try like we did just now can show how much we have in managing — or even taming — CSS cascades. Buttons are deceptively complex, but we see how many styles are needed to handle styles from default styles to writing their state and modified versions.

The above is the detailed content of Organizing Design System Component Patterns With CSS Cascade Layers. For more information, please follow other related articles on the PHP Chinese website!