The two don't have to fight necessarily but generally I'm in agreement that the "OOP CSS" people generally don't have a clue about good programming or good CSS. Some do, but a lot don't.
First of all when people talk about OOP-style CSS, what they're really talking about is a componentization scheme. Not OOP. That they're willing to call it OOP is an argument against it in and of itself. Kool Aid has been mixed and it is being drunk.
Multiple classes used to compose the styles for one element is actually very similar to an inheritance-heavy scheme in OOP. Both are equal parts stupid and needlessly couple concerns by making one set of properties a dependency of far too many things for you to ever change it without running into all sorts of trouble across your entire app. You can have categories of classes define certain subsets in such a way that it does in fact become easy to swap one out for another with little trouble but this puts a pretty hefty burden of competence on typical devs that don't immediately see "OOP CSS" for the oxymoron that it is. But ultimately it's not really designed that way so why do it like that? HTML and CSS work best when you work with how they work, not with how some serious-sounding acronym approach wants them to work.
That said, CSS isn't really designed as semantic either, but it is worth following a similar strategy. Where HTML should mostly describe content, html ID and class names should NOT describe what the CSS or JS bound to them actually do. shiny_red_button IMO is a lousy name for a CSS class. For as design churns, one day your button may not be so big red and shiny even though the button still specifically handles panic and should thus be called 'panic' or perhaps 'panic_btn' if you like denoting the sorts of elements it typically applies to.
I go with the following general rules
- Don't describe looks or details of a handler in ID or class names.
Be kinda-semantic. The HTML gives us a general idea of what will be found within. Now get a little more specific as to its design purpose.
- Use as few selectors as possible always
The thing that OOP-style CSS thinks it's reacting to is specificity run amuck. Fail. Specificity is not the enemy. It is a tool that you either use well or misuse. So when somebody says "Don't use IDs because they're harder to override" slap them or have them consider this:
#unique_element_container_on_page > a vs. .unique.element.container.on.page > a
If there is one thing that should profoundly offend designers, ui devs, and app/server-oriented devs equally, it's having to !@#$ing count something (like say a java method with 20 optional parameters) to figure out what you need to do next.
Said again because I think CSS lint is being silly.
- Let context do the polymorphing
HTML is basically taxonomy. Broad categories that fit less broad categories that keep working their way down to specific/unique things. CSS works best when following along with this scheme. Sections may have variations on an even more general theme.
Overriding that theme with a section class followed by whatever descendant is different usually makes a lot more sense than writing a new css component class and dropping that in on the specific element that's different to replace an old one. Intent is more clear and you have fewer dependencies per element to trip on. Except of course when the theme variation isn't really related to where an element is placed. That's one of those rare cases where I'll bust out a comma and add a selector to an existing one and then define its variant properties immediately following with just the new selector. Do enough of that sort of thing and you can white label swap with a simple class change at the top of the page in your HTML.
- It is okay to repeat yourself
Use DRY as more of a smell detector than the golden rule with rare exceptions that it is in programming. In CSS it is far more common for two almost like property sets to be like by coincidence, not because their selectors share a purpose. It's better to leave them separated for the day that someone will want to change one and not the other. An ideal CSS file works much like a control-panel where it's reasonably easy to find what you need in order to change something with confidence that you won't also change something else by accident.
