Split utilities from property utilties and get more control over generation of property utilities

Split utility groups

In v4 we have 2 different kind of utilities that are a bit mixed in the documentation and in the code.

The first group is what I call the normal utilities. These utilities have more than one property and don’t have the !important suffix. These utilities are:

• Clearfix
• Embeds
• Text hide
• Fixed top, fixed bottom & Sticky top
• Screen reader utilities
• Stretched link

The second group is what I call the property utilities. These utilities typically have one property (except for .mx-*, .my-*, .px-* and .py-* utilities) and always have the !important suffix.

I think we should split these utility groups. Not sure how we should call them, but for now I’ll call them the utilities and property utilities.

More control over property utilities

We got a lot of requests and PRs about the generation of more responsive properties (for example responsive border utilities https://github.com/twbs/bootstrap/issues/28191) but we can’t just add utility classes for all the properties because this will increase the size of the css too much.

On the other hand there’s a need for more control over the generated code (which is also mentioned in https://github.com/twbs/bootstrap/issues/25941).

On yet another hand (let’s just assume there’s a third hand somewhere) I sometimes have the need to extend the utilities for more properties like opacity or other properties Bootstrap doesn’t cover with utilities.

To tackle this problem I’ve started developing something to gain more control over property utilities, with some kind of API where you can choose whether you also want to have responsive utilities, but before I’m going to continue with it, I’m going to check for some other opinions here. It 'll probably also need some solid documentation to explain it all.

I’m working under v4-dev-mc-poc-property-utilities, the branch will need to be renamed, because this will not land in v4, but maybe something for v5 if I can get to something ready in time. You can see the diff here: https://github.com/twbs/bootstrap/compare/v4-dev-mc-poc-property-utilities?expand=1#diff-1500afbbcf5fcafdd95fddb9b709de83 scss/_property-utilities.scss and scss/utilities/_property-utilities.scss will probably be the most interesting files.

What do you think?

@ysds @gijsroge @twbs/css-review

[mdo]

Yaaasssssssss this is the kind of discussion I’ve been waiting for! 😄

I’ve been thinking about this on and off for awhile now. I want to keep Bootstrap, especially it’s most powerful features as approachable as possible to the greatest number of people. As it stands now, this feels a bit too verbose, which is a bit of a turn off for me. That’s from a maintainer perspective, but as I think about how much work would be required to remove, add, or change one of these, I wonder if it could be simpler.

Here’s the idea that’s been floating around in my head—one giant Sass map that we loop over to generate all our responsive utilities. Each nested map could have additional controls for responsive variations (default false for file size), inclusion of print variants (default false), and ideally even overrides for which breakpoints to include (default all, optional to declare specific ones from the $grid-breakpoints map).

$utilities: (
  display: (
    class: d,
    values: none inline inline-block block table table-row table-cell flex inline-flex,
    responsive: true,
    print: true
  ),
  
  font-weight: (
    class: text,
    values: (
      light: 100,
      lighter: lighter,
      normal: 400
      bold: 600,
      bolder: bolder
    ),
    responsive: false, // Default value perhaps?
    print: false // Default value perhaps?
  ),

  // and so on...
) !default;

Thoughts on a direction like this?

[gijsroge]

This is some great work Martijn 🤘

Maybe something like helpers & utilities?

My understanding of the word “helper” in this context is that it provides more than one property to assist in achieving something.

About the need for more control over utilities.

I think the extending property utilities is impressive and a smart way to build utilities and giving users a way to come up with own property utilities. You pretty much nailed this imo.

However I would give the idea of providing a full blown optional pre-made utility set a though. Otherwise, people who intensively uses utilities are required to build or copy paste their own utilities over and over again (me included 😁).

This however needs to be in line with the vision of Bootstrap, because it will start to look a lot like a utility framework (which is great thing imo).

Maybe the only thing I can see not working with this is generating responsive helper classes, for example the sticky top helper could use the same benefits as utilities regarding responsive classes. I can see a use case that I would only want the sticky element to be sticky on desktop.

Something to think about maybe?

One possible solution would be to just refactor those existing helpers (#28352) with responsive classes 😁

About the need to provide a way for users to remove unused code

Maybe another way of tackling this is to provide a small section in the docs on how to use PurgeCSS instead of Uncss. I know PurgeCSS has the option to parse javascript for classes so dynamic classes are discovered as well.

extra info on PurgeCSS docs

This would basically parse all your templates, javascript, Sass, to discover all possible used classes and removes the other ones. Very good stuff if you are heavy on utilities 😃

Other stuff I might consider refactoring

Confusing naming collisions with .btn-sm, .btn-group-sm, .custom-select-sm, .modal-sm, .rounded-sm, .shadow-sm, etc…

Especially .shadow-sm, .rounded-sm are super confusing regarding the responsive naming convention used in the current version of Bootstrap.

I very much like the way Tailwind CSS uses a responsive namespace, like sm:, md:, etc… maybe something to look into, i’m not sure what the intend of v5 is, but this would cause a lot of breaking changes.

An other possible solution for this is to rename the .btn-sm, .modal-sm to .btn-small, .modal-small. But I personally prefer the namespacing to make it extra obvious. Or even do both, that would make it even more clear. So sm:shadow-small, lg:rounded-small.

But maybe this should be a separate discussion…