[Context - I'm a Java developer, having a discussion with a designer who works in the html/css space]

I was having a discussion with a co-worker today about the merits of 'semantic css'.

His response was, "Oh we're not interested in semantic css, we use object oriented css"

I understand what he means, ie that they're using the 'inheritance' properties of css and SASS mixins to describe styles. But I feel like he has not tried to understand 'semantic css'.

I'm trying to construct a cogent argument about why 'object oriented css over semantic css' is flawed.

This is my reasoning so far:

My question is "what are some cogent arguments explain semantic css to someone who thinks that 'inheritance', 'classes' and 'mixins' make something object oriented and that he doesn't need to worry about good naming?"

  • I see nothing wrong with object-oriented CSS. <input type="submit" class="big blue button"> is perfectly readable to me. As it <input type="submit" class="small red button">
    – user16764
    Commented Aug 29, 2013 at 4:42
  • 1
    All well and good until you go white label and "big blue button" is more of a yellow/tan camoflauge-ish type thingy in one of your other offerings and now you're branching html AND css just to keep things legible. Commented Aug 29, 2013 at 5:25
  • 3
    Honestly, IMHO it may help to put those buzz-words away in your discussion and focus on how the naming scheme could be improved applying some common sense.
    – Doc Brown
    Commented Aug 29, 2013 at 10:59
  • I'm with Doc Brown. It's amazing how often people get lost in buzz words and patterns and lose sight of the problem that needs to be solved.
    – 17 of 26
    Commented Aug 29, 2013 at 13:07
  • 1
    Who says "semantic css" and "object oriented css" are mutually exclusive? (Other than your coworker ...)
    – svidgen
    Commented Aug 29, 2013 at 14:00

3 Answers 3


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.

  • IDs are okay.

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.

  • Struggling with Bootstrap and how it names classes to indicate how many columns are spanned. Presentation? Structure?
    – user251748
    Commented Jan 12, 2018 at 15:41

I personally can get on board with a nice balance of the two where in you have oocss for helpers and you have semantic css for components... and the decision to create a component would come in when you find yourself applying the same oocss elements repeatedly.

I don't get why people are so all or nothing, there needs to be a balance, one nice thing about a balanced approach is the ability to have an over-ride on a semantic class using oocss... so say you have a container defined that has all of the properties you want but you want blue text instead of black, you can use your semantic class followed by a blue text color class and css hierarchy will respect it. This means you don't have to bloat your css with another almost identical semantic component and you don't have to write any css at all, just drop in two classes and you're done...


Thanks for your comments - I've been able to clarify my thoughts on this.

The distinction between the two seems to be on workflow. The former (object oriented css) is more of a traditional print based approach where colours and styles are chosen first for a branding goal, and then the website is assembled from that later. The latter (semantic css) approach is more clearly linked to a website design goal, where a site can be built and the styles can be easily tweaked later, without necessarily changing the code on the page.

If you have a workflow that goes graphic designer does colours and style -> css designer -> web developer, and the styles are unlikely to change - then an object oriented css approach is more appropriate (but less flexible later).

If you have a workflow where the graphic designer and css person will work iteratively to tweak the website to a particular goal - then semantic css is more appropriate.

The big distinguishing criterion is that semantic css allows customisation to the site by changing the style without the site.

(There is probably an outstanding question about whether the design goal of css intended you to be able to tweak the site without changing the code of the page - but that's a discussion for another day)

(I do appreciate the comments that say that good naming is the main thing you're worried about. My point is that you should name the page elements first and then build styles from that - rather than build css elements and then pick and choose them into your page)

  • This needs to be an edit to your post, not an answer.
    – user28988
    Commented Aug 30, 2013 at 14:08
  • With Responsive design, I am perplexed by where the adjustments should be specified. I was OK with the idea that all media adjustments should be in the CSS - that is what it is for. But I am reading about Bootstrap, and it includes classes which are used in the HTML to say things like: "this element should span 4 columns on a medium device and 6 on a small device (and where not specified, span all columns)." This seems to mix up structure and presentation in one spot (and in the HTML at that), something that I am still trying to grok the necessary and important distinction for separating!
    – user251748
    Commented Jan 12, 2018 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.