Make it clear that utils configuration has a impact on variant generation

[thiagomajesk]

As commented here: #828 (comment), while customizing DaisyUI, I caught an unexpected "issue" where variants like alert-info were not being generated. The thing is, for this class to be generated properly, one has to have the utils config set to true. The problem here is that the docs do not make this sufficiently clear IMHO. It doesn't help much that while having utils set to false, the btn-info variant is generated while alert-info is not - which can cause confusion.

Now, I'm not sure if the best approach is to document this behavior or if variants like btn-info should be bound to the same constraints as other components.

[saadeghi]

It is specified on the docs here:
https://daisyui.com/docs/config/

utils

Boolean (default: true)
If it's true, responsive and utility classes will be added

And you can see all the class names considered as utils right there in the link

Let me know if you have any questions

[thiagomajesk]

@saadeghi I've read the docs, especially this section and I think that the confusion lies on how the framework is dealing with all the "variants". So, I'm looking at the component pages here and btn-info is categorized as "modifier" while alert-info is categorized as "responsive". Is this by design?

It seems weird that similar class names are categorized in different ways from component to component. If I may ask, what's the reasoning behind this convention? Seems very confusing.

[saadeghi]

I might need to make it more clear but here's how it is:
btn is the component class.
Every other class name that we use alongside that, would be a modifier
Modifier classes using just change the color or size and some of these modifier classes are responsive modifier classes.
It might be confusing at first but these are the best names I found to categorize the class names. Part of it is inspired by Tailwind CSS structure and part of it by BEM.

Let me know if you have any questions

[thiagomajesk]

I might need to make it more clear but here's how it is: btn is the component class. Every other class name that we use alongside that, would be a modifier Modifier classes using just change the color or size and some of these modifier classes are responsive modifier classes. It might be confusing at first but these are the best names I found to categorize the class names. Part of it is inspired by Tailwind CSS structure and part of it by BEM.

Let me know if you have any questions

Cool, what hasn't clicked for me yet is why alert-info is considered a responsive modifier while btn-info is just a "modifier".
I'm asking because there's clearly a differentiation here; one is generated with utils: true and the other is not.

PS.: Looking from the outside, It seems that "simple modifier" classes should be used for variants like btn-info and alert-info, while "responsive modifier" should be used for actual responsive functionality!? It's not clear to me what's the difference looking at these two similar examples which supposedly do the same thing (btn-info and alert-info).

[thiagomajesk]

@saadeghi I'm gonna give some examples of what I'm talking about:

class	type
btn, alert, badge, card, stats, tooltip, input, range, carousel	component
radio	modifier
btn-primary, radio-primary, tooltip-primary	modifier
alert-info, badge-info	responsive
btn-lg, range-lg	responsive
radio-lg	modifier
btn-square, card-normal, stats-vertical	responsive
stats-vertical	responsive

We have main components mostly defined as a "component" class. However, radio is listed as a "modifier" while input, which is in the same "category" (forms) is a "component". Variant classes like *-primary|info|success range from "modifier" to "responsive". Sizing classes *-xs|sm|lg range from "responsive" to "modifier" and other classes that change the behavior of a component like stats-vertical or card-normal are either "responsive" or "modifier".

If I can make a suggestion I'd standardize class names by making all current components consistently be named "component", sizing utilities be called "sizing", color variants like primary, and info be called "variant" and everything else that can change a component's behavior to be a "modifier".

Of course, the main question here is not about the naming conventions chosen. Although it helps, I think the main problem is presented by the surprise that similar scoped classes are treated differently by the framework.

[thiagomajesk]

Ping @saadeghi.

[saadeghi]

Sorry I missed this issue since it wasn't open. I will check it soon.

[saadeghi]

class name categorizations for alert, button, radio and badge has been reworked in daisyUI 2.24.0
Some class names were in the wrong categories.

• Now all the class names that modify colors are modifier
• All class names that modify sizes are responsive

Let me know if you have any questions.

[thiagomajesk]

Great work @saadeghi!!! ❤️🖤💙🤍💛🧡💚💜🤎