Utility API generates "inconsistent" class-names when omitting the "class" option

[thiagomajesk]

I'm using Alpha 3 and noticed that the utility API is a little bit inconsistent when generating utilities without the "class" option.

Using this config:

"block": (
  responsive: true,
  property: display,
  class: null,
  values: block
 )

Expected:

// ...
.block-sm {
  display: block;
}
// ...

Got:

// ...
.sm-block {
  display: block;
}
// ...

Another example would be:

"box-sizing": (
      responsive: true,
      property: box-sizing,
      class: box,
      values: (border: border-box, content: content-box)
)

Which yields:

//...
.box-sm-border {
    box-sizing: border-box !important;
}
 .box-sm-content {
    box-sizing: content-box !important;
}
//...

If you specify a value that is null or empty for the "class" option, you don't get a "properly-named" utility.
BTW, I'm not sure if "inconsistent" is the right word for it, but I think this is a use-case I was hoping was supported. It allows us to generate less verbose utilities when the property value is the same as the class-name (instead of display-sm-block or block-sm-block, for example).

My proposal is to swap the "responsive" and "name" strings when generating utilities if the class option is null so you can generate classes like block for display: block, etc.

Update: I don't know if this interferes with the current naming schema for the responsive classes like d-block or d-sm-block where the breakpoint comes first, but... wouldn't it actually be more intuitive if the breakpoint was at the end of the class-name or prefixed like Tailwindcss? eg: d-block-sm, sm:d-block. This way it wouldn't be a problem when you concatenate the names and it seems a much cleaner solution to avoid mixing the prefixes.

On another note: Maybe the "class" option should be called "prefix" since this seems to be what it does. Also because you can change the actual class name by using the map notation on the "values" option (the final class name then is a combination of factors).

PS.: I know that the same thing happens if you generate responsive utilities for the "overflow" property that comes with Bootstrap, you'll get class-names split by the breakpoint suffix: overflow-sm-auto and overflow-sm-hidden are other examples - so this might be by design (I'm just finding it supper weird now that we are relying even more on utility classes).

[XhmikosR]

I think this is what we hit the other day in the RTL PR @ffoodd?

[ffoodd]

Not sure about what you're referring to, but this is clearly by design since every given examples is the expected output ATM.

There's no bug nor issue here—only questionning our naming convention for utilities.

Using prefix instead of class makes sense.

Moving breakpoint at the end/start of utilities is questionnable, IMHO. That's a convention, it's been Bootstrap's one for years, and as soon as it's documented and known I don't see the point of changing our convention.

BTW, maybe I'm too used to Bootstrap but having d-block d-lg-none seems clearer to me than d-block d-none-lg for responsive variations.

[mdo]

Yeah, we're locked in for the naming because of the beta, but this also makes sense as it is—d for display comes before -sm-block, so it follows that you get sm-block at the other end without a class. Closing as a won't fix.