Albert Diones

Why I hate HTML Classes that describe style | Coding Conventions that I think is a thing

It is very common for HTML classes to follow some framework that "make it easy" to create style. But I absolutely hate it because it is an obstacle more times that it is helpful.

Here's some reasons why that I won't get into much deep since this is just a quick blog post to map my ideas in the future

1. It makes modularity a nightmare - when making includeable repeatable modules, you have to tweak styles. Now that you have a class for that button as "color-red" use in page type#1, how are you gonna use it on page type #2 without putting a weird workaround like variable or an if statement, are you gonna do that for every variety?
2. It makes status changes weird - whenever the state of the document is changed, you have to find all elements you want to change and remove the styled class you put and put in a new one: (e.g. several green button needs to be gray for a few seconds, then turn green again later, now you have to get all green buttons, remove the bg-green, then replace it with bg-gray) too complicated
3. Responsiveness is weird - almost every framework has it's own convention on how they name things, small that, big that, large that xxx-large and they all have their own definition

Proposed solution:

Use classes that represent the state of the document or the element, not the style of it:

• is-logged-in, is-loading
• loaded
• is-active, not-active
• is-agreed
• is-valid
• not-valid

I may write another post about "state classes" but it is so much better than style classes