Different Degrees of Custom Property Usage

One way to use custom properties is to think of them as design tokens: colors, spacing, fonts, and more. You can set them at the root of the page and use them throughout the CSS. Very useful and over the past million years, not only custom properties, but classic use cases for preprocessor variables.

Another way to use (which can be used in conjunction with the design token method) is to use them more thoroughly for each major unique style choice on any given element.

Suppose you have a card like this (simplified for demonstration purposes):

 <code>.card { background: hsl(200deg 15% 73%); border: 4px solid rgb(255 255 255 / 0.5); padding: 2rem; border-radius: 8px; } .card > h2 { margin: 0 0 1rem 0; border-bottom: 3px solid rgba(0 0 0 / 0.2); }</code>

very good.

However, when you inevitably make variations of cards, you need to override these rule sets yourself. The CSS custom attribute method can be like this:

 <code>.card { --card-background: hsl(200deg 15% 73%); --card-border: 4px solid rgb(255 255 255 / 0.5); --card-padding: 2rem; --card-border-radius: 8px; --card-title-margin: 0 0 1rem 0; --card-title-border: 3px solid rgba(0 0 0 / 0.2); background: var(--card-background); border: var(--card-border); padding: var(--card-padding); border-radius: var(--card-border-radius); } .card > h2 { margin: var(--card-title-margin); border-bottom: var(--card-title-border); }</code>

At the moment, it's a little bit longer, but look at what happens when we want to make a variation:

 <code>.card-variation { --card-background: purple; --card-padding-block: 2.5rem; --card-title-margin: 0 0 2rem 0; }</code>

Here are three obvious advantages:

• I've changed only the values ​​that are explicitly set to changeable. My main card prototype keeps the integrity I want it to maintain.
• I can style the child elements of the variant without rewriting these selectors correctly.
• I can now pass style overrides from the style attribute in HTML for a quick one-time variant.

Use fallback to reduce redundancy

Instead of declaring custom properties at the top and then using them below, I can do it at the same time in this way:

 <code>.card { background: var(--card-background, hsl(200deg 15% 73%)); border: var(--card-border, 4px solid rgb(255 255 255 / 0.5)); padding: var(--card-padding, 2rem); border-radius: var(--card-border-radius, 8px); } .card > h2 { margin: var(--card-title-margin, 0 0 1rem 0); border-bottom: var(--card-title-border, 3px solid rgba(0 0 0 / 0.2)); }</code>

Now, if a property like --card-background is set, it will override the fallback value here. I don't quite like this because it means that the element above the .card can overwrite it. This may be what you want, but this is not exactly the same as declaring the value at the .card level at the beginning. There is no strong opinion here.

Further decomposition

An example here is that you might want to control the padding separately.

 <code>.card { --card-padding-block: 2rem; --card-padding-inline: 2rem; --card-padding: var(--card-padding-block) var(--card-padding-inline); padding: var(--card-padding); }</code>

Now, if I want, the variant can control only part of the padding:

 <code>.card-variation { --card-padding-inline: 3rem; }</code>

But you have to be aware of a big problem. This means that if you declare all of this at the root, this won't work because these nested properties have been parsed. But as long as it is declared on the .card first, you'll be fine here.

Overdoing it?

Suppose you want to have super-ultimate control over each part of the value. For example:

 <code>html { --color-1-h: 200deg; --color-1-s: 15%; --color-1-l: 73%; --color-1-hsl: var(--color-1-h) var(--color-1-s) var(--color-1-l); --color-1: hsl(var(--color-1-hsl)); }</code>

It's a little clever, but it may be too much. The colors will almost certainly be declared at the root and remain unchanged, so this big problem will make it impossible to overwrite low-level sub-properties. Also, if you have --color-1, you probably have 2-9 (or more), which is great because the color system is much more refined than the math of the simple color part.

Deliverable design system?

There is no doubt that Tailwind is very popular. It uses atomic methods, where a large number of HTML classes control a property separately. I think part of the reason it's popular is that if you choose from these preconfigured classes, the design ends up being pretty good. You can't go off track. You choose from a range of finite values ​​designed to make it look good.

I wouldn't say that the style method based on custom properties is exactly the same. For example, you still need to consider class name abstraction instead of applying styles directly to HTML elements. However, it may enjoy some of the same constraints/restrictions as Tailwind and other atomic class methods. If you can only choose from predefined --spacing-x values, --color-x values, and --font-x values, you may achieve a more cohesive design than ever before.

Personally, I find it feels good to move towards a design system that relies more on custom properties – if nothing makes variations and coverage easier to manage than this.

How do third-party design systems take the features they provide as...just a large set of custom properties for you to use at will?

Third-party deliverables don't even have to include everything like this. For example, Adam Argyle's transition.style provides a "Hackpack" that is simply a custom property of the transformation animation helper.

Understandability cost

One argument I've heard against this more comprehensive approach to custom properties is newbies understandability. If you wrote the system, it might make a lot of sense to you. But it's an extra abstraction on top of CSS. All people share CSS knowledge, while custom system knowledge is shared only by people actively involved in the system.

Systems that are new to using custom properties will have a very steep learning curve.

video

The above is the detailed content of Different Degrees of Custom Property Usage. For more information, please follow other related articles on the PHP Chinese website!