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.
I should clarify, it makes the production code more complex and harder to read, not the source code. Yes it spits out files with 1000's of css but I don't care about minified production code's readability or complexity. I care about the source code I maintain and manage. Like I said, I'm not some tailwind advocate but it has gained traction for a reason.
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.
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.
I should clarify, it makes the production code more complex and harder to read, not the source code. Yes it spits out files with 1000's of css but I don't care about minified production code's readability or complexity. I care about the source code I maintain and manage. Like I said, I'm not some tailwind advocate but it has gained traction for a reason.