Adding !important for util classes

[willmcvay]

Ok, so we all know !important rules should be used sparingly in CSS. There is however a use case I can see in Elements where it makes sense and I think would be generally accepted as valid i.e. utility classes. Wanted to float this with the team before thinking about implementing.

Consider this example:

.el-card {
  margin: 1rem;
}

.el-mb-12 {
  margin: 3rem;
}

<div class="el-card el-mb-12">Content</div>

I think it seems reasonable that the .el-mb-12 modifier would only be applied by a developer if they wanted to override the default behaviour of .el-card - I can't see another use case. Because the rules are equally specific, the winning rule will depend on which selector is loaded last which seems like a pretty rubbish edge case.

Consider if I increase the specificity on .el-card

.el-card {
  &.el-is-active {
    margin: 1rem;
  }
}

.el-mb-12 {
  margin: 3rem;
}

<div class="el-card el-is-active el-mb-12">Content</div>

In this case because the .el-is-active class increases the specificity, the .el-mb-12 modifier is rendered totally useless. If the developer intention was to add the modifier, their expectation surely would be that the modifier would win, right?

Proposal: Add an !important to util classes

Brutal, yes, but if the sole purpose of util classes is to override default behaviours, seems reasonable that we would guarantee that the override works in all use cases.

Our modified example:

.el-card {
  &.el-is-active {
    margin: 1rem;
  }
}

.el-mb-12 {
  margin: 3rem !important;
}

<div class="el-card el-is-active el-mb-12">Content</div>

In this case, our modified margin would always work. If the important flag is causing any inheritance issues, we can easily remove it without too much of an issue. My sense is, it's a far lesser evil that we use !important for utilities only than having to worry about those utilities not working in some scenarios.

Please comment, upvote or downvote as something we can look at in v5.

[kurtdoherty]

@willmcvay Being quite unfamiliar with using Elements directly, what you've proposed may be fine, so I have some clarifying questions to ask before weighing in:

1. Is it common for margins to be baked into components like you show above?
2. Is the use of CSS utility classes only relevant for consumers that are using the CSS stylesheet and not the React components, or does this apply to our implementation of React components in Elements as well?
3. What other kinds of CSS utility classes are regularly used? Are they just concerned with spacing (like padding and margin), or are there also utility classes for font styles, borders etc also available?
4. Why are these CSS utility classes used (e.g. why is a developer overriding a Card's styling?) and are those reasons valid/acceptable in the context of the Design System and its guidelines?

FYI I think answering #98 would help provide some clarity here too 😅

[willmcvay]

Hi @kurtdoherty,

To answer;

1. It's a bit of a contrived example and not one actually from the code. Most spacing is handled by grids and grid spacing however, on say the Title component, yes, there is a default margin you may wish to override.
2. Both, we use them internally for small tweaks
3. See the docs https://elements.reapit.cloud/?path=/docs/utilities--docs and https://elements.reapit.cloud/?path=/docs/flexbox--docs for example
4. Like I say, contrived example to illustrate the core point - utils are used sparingly generally. In a dream world every design for a page we implement would be 100% DS compliant but in the real world, designs do deviate from the vanilla and it is sometimes necessary to make a small tweak here and there - a bit more padding on x or more margin spacing with y. It's intended as an escape hatch to avoid having to write a custom class.

[kurtdoherty]

Thanks @willmcvay 🙌

It's intended as an escape hatch to avoid having to write a custom class.

Yes, we absolutely need escape hatches. I'd be interested to learn more about why the team has taken the "avoid having to write a custom class" approach (is this what Linaria's styled and css utilities result in?), but maybe that can be done in a separate discussion.

My sense is, it's a far lesser evil that we use !important for utilities only than having to worry about those utilities not working in some scenarios.

This seems reasonable to me, but I do feel like the use of utility classes is a signal that something else in the library is not quite right. For example, maybe we missed a use-case for a particular component and hardcoded some styles that should actually be specific to a different variant of that component; or perhaps Design has tweaked the component in Figma, but we haven't implemented those changes in Elements yet.

[willmcvay]

This seems reasonable to me, but I do feel like the use of utility classes is a signal that something else in the library is not quite right. For example, maybe we missed a use-case for a particular component and hardcoded some styles that should actually be specific to a different variant of that component; or perhaps Design has tweaked the component in Figma, but we haven't implemented those changes in Elements yet.

Probably a bit of all of these TBH @kurtdoherty . It's not something we widely use, more just a convenience to cater for the odd edge case that arises. It's not a vanilla flow we are talking about :-)

[willmcvay]

Yes, we absolutely need escape hatches. I'd be interested to learn more about why the team has taken the "avoid having to write a custom class" approach (is this what Linaria's styled and css utilities result in?), but maybe that can be done in a separate discussion.

Sure, you can do this too - just keeps things DRY if we have commonly used modifiers as utilities