To your point, no it doesn't make style declaration cleaner, it makes it so you don't have CSS files 1000's of lines long with 100's of unique classes defined that have maybe 1 or 2 property differences.
And I would say that is a sign you need to learn how to use CSS, not change your tool. For one, knowing when to attach a style to a generic element type or class name as opposed to using a utility class is essential, and many people just never bother figuring this out.
That's why I think it's silly when some people pretend that tools like tailwind don't let you get around learning CSS, because you have to know CSS to use TW effectively. I hear this often as a defence when people don't want to admit that they just don't want to learn actual CSS. It shows that they don't even know what they don't know, because the only way anyone could reach a conclusion like that is by believing CSS is nothing more than knowing some property names and maybe understanding how flex works.
This is both insulting to anyone who actually takes the time to learn CSS properly, and paints a very questionable picture of those TW advocate, making it hard to take their word for anything CSS-related.
Almost none. To be honest, I can't remember having that problem at all. Following a methodology similar to BEM (not necessarily BEM) will avoid that problem completely. If your class is something like module-component-element, you will not get name conflicts and it will be easy to know what each class represents (both in HTML and CSS).
I've never liked BEM much, and tend to opt for more of an axiomatic approach to CSS, and I can confirm that I also don't usually deal with these problems. More precisely, it usually isn't a problem, because when I change a rule like "h1 { color: red; }" to "h1 { color: blue; }" it's because I want it to affect headings everywhere.
I call that consistency, and file it as a good thing in the general case.
When I'm dealing with more specific scenarios, I will usually just write more specific rules to reflect that, and tell the browser where or when I want the heading to be blue. Sometimes this even helps me catch myself when I'm using the wrong sort of element or my HTML structure is just weird, which happens relatively often when you're focusing how your page looks.
And in very special cases, adding a style attribute is always an option, if I know a change is specific to one exact situation.
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
That is to understand CSS and match elements to a style guideline: things that must move together should move together, while exceptions should be local (unless there is another general rule).
It is a very good explanation and I encourage you to write an article on it. We need more of this to be out there and we need to convince people that reasonable CSS can be short, terse and clean.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
And I would say that is a sign you need to learn how to use CSS, not change your tool. For one, knowing when to attach a style to a generic element type or class name as opposed to using a utility class is essential, and many people just never bother figuring this out.
That's why I think it's silly when some people pretend that tools like tailwind don't let you get around learning CSS, because you have to know CSS to use TW effectively. I hear this often as a defence when people don't want to admit that they just don't want to learn actual CSS. It shows that they don't even know what they don't know, because the only way anyone could reach a conclusion like that is by believing CSS is nothing more than knowing some property names and maybe understanding how flex works.
This is both insulting to anyone who actually takes the time to learn CSS properly, and paints a very questionable picture of those TW advocate, making it hard to take their word for anything CSS-related.
I've never liked BEM much, and tend to opt for more of an axiomatic approach to CSS, and I can confirm that I also don't usually deal with these problems. More precisely, it usually isn't a problem, because when I change a rule like "h1 { color: red; }" to "h1 { color: blue; }" it's because I want it to affect headings everywhere.
I call that consistency, and file it as a good thing in the general case.
When I'm dealing with more specific scenarios, I will usually just write more specific rules to reflect that, and tell the browser where or when I want the heading to be blue. Sometimes this even helps me catch myself when I'm using the wrong sort of element or my HTML structure is just weird, which happens relatively often when you're focusing how your page looks.
And in very special cases, adding a
styleattribute is always an option, if I know a change is specific to one exact situation.That is to understand CSS and match elements to a style guideline: things that must move together should move together, while exceptions should be local (unless there is another general rule).
It is a very good explanation and I encourage you to write an article on it. We need more of this to be out there and we need to convince people that reasonable CSS can be short, terse and clean.