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
- 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?
- 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
- 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
Comments (0)
Add a Comment