Hi everyone,
A problem that I come across often is that I define color and font properties repeatedly across many elements in CSS.
For example, if I have 3 divs, I would find myself defining font property for elements inside the 3 divs individually.
There is obviously a best practice I am not aware of.
Thanks for any ideas!
You can use CSS more efficiently than that. You can do things like:
.div1 p, .div2 p, .div3 p, .div1 h1 {color: #222;}
Perhaps give a more specific example of the HTML you are trying to style.
Some people like to create typography classes (or themes) that carry the relevant font and colour information only and then just apply the class as required.
This can cut down on repeating css properties but does mean that extra classes have to be added to the html instead which is not always a good thing.
I don’t really like that method as it splits styles up and I find that hard to manage. I like all my rules in one place. However some people find it useful especially if you keep changing color themes as all the typography is in one place.
I usually group the rules together as Ralph suggests to cut down on code.
Like Paul, I haven’t really been convinced by the ‘object oriented CSS’ approach, but anyway, here’s an interesting example of it that I stumbled on recently:
Meet Object Oriented Css Cut The Fat Out Of Code With This Smart Time Savin | Articles | Meta Q
This thread is similar to this one: http://www.sitepoint.com/forums/css-53/object-oriented-css-uses-learning-newbie-740553.html, and in there, all the details have been already talked up and down.
The simple fact is that OOCSS is a concept, it’s not a spec, a framework or something to rely on.
And that concept is born from the fact that facebook has a very specific type of content, with a small repetive mark up structure in its midst.
Where they go false in the statement that “OOCSS cuts code down” is when they don’t say: “it is specifically for sites having a certain type of mark up repeating over and over”. It will “cut” the code down for a specific type of sites. And it’s not really cutting, it’s structuring. One thing facebook didn’t manage to do from the beginning. And they call the necessary correction “improvement”: OOCSS. Yeah, right! facebook, we know you had crappy code to begin with, no reson to be ashamed now! 
That, and the fact that, it’s not “OOCSS” it’s more like .class. 
But, the Nicole person starting all this, find it a way to make it sell. She said: “OOCSS, it’s new and bright and shinny”. But those who know can tell that a simple class would do the job. In fact, using classes is the right way to go, and you can call them whatever you like: mediaObject, commentWithImage, moneyMaker. 
She hoped that by throwing CSS Layout Grids into play, we would all forget about the basics of HTML structuring and CSS classes, and we would call an old-as-granny thing like she wants: OOCSS, “HTML object”. And she’s throwing at us the worst examples she could find on web to make us believe that’s the way. It’s a simple techniques: first say a truth, then bring in a twisted lie, and by asociation, make the lie sound like a truth.
What she doesn’t tell you, is that by adopting “OOCSS”, you adopt a strange, unexisting form of “proprietary” CSS and HTML, that will close up on you, much like using tables for layout closed up on many. What’s she’s preaching it’s not flexibility, it’s productivity, in a wrong way. Since productivity it’s not a bad thing at all, when done properly.
So, to answer haopei, the best I can, since I have no proposed mark up: you do it like this:
<div class="haopei">
<p>haopei is smart not to believe in OOCSS
</div>
<div class="haopei">
<p>haopei is smart not to believe in CSS grids
</div>
<div class="haopei">
<p>haopei is smart not to believe in anything that's not documented or well thought up
</div>
.haopei p {
/* ways to show haopei is smart ;) */
}
I’ve tried a couple of work methods to achive pseudo-OOCSS, such as splitting layout, type, tables, forms, etc. into their own stylesheets, using “helper” classes to store commonly used properties. And both of these lead to clutter, either on the css files, with massive code duplication or on the markup side with tons of classes being applied to elements.
I now simply write my code and every now and then i “compile” repeated stuff with multiple selectors to reduce the amount of code.
I prefer this TLA approach to CSS:
.bgr {background-color:#f00} .bgg {background-color:#090} .bgb {background-color:#9ff}
.fll {float:left} .flr {float:right}
.fs2 {font-size:2em} .fs3 {font-size:3em}
.fwb {font-weight:700}
.mga {margin:auto}
.poa {position:absolute}
.w32 {width:32%} .w66 {width:66%} .w88 {widh:88%}
# Usage:
<div class='w88 mga fs2 fwb'>
<div class='fll w32 bgr'>
Red
</div>
<div class='fll w32 bgg'>
Green
</div>
<div class='fll w32 bgr'>
Blue
</div>
</div>
I think where this concept really shines is when dealing with redundant components. For example, I have been building a real estate admin system that involves repeating many of the same components within different contexts. Some examples of those components are: data entry form, data grid, search filter and tabbed menu. The data entry component is a form, data grid form with table in it and search filter is a form. Therefore, using a mere “form” selector is not enough to distinguish between the different contexts which the form is used. The other option would to do it based on page detection. However, that results in repeating a a bunch of different rules like: “.page-agents form,page-listings form, etc”.
Instead the concept that embodies oocss is used by merely applying a class to the root level container of the component. So with my previous examples data grid would be .data-grid, data entry form would be .data-entry and the search filter would be .data-filter. From there I can easily target any child element of said component and provide a base theme/styles for each. I also apply an additional class to each that supplies the context which the component is being used. In the case of a real estate system those entities being: office, agent and listing to name the major ones. Therefore, to target the data entry form for an agent because it needs slightly different styles is merely: ‘.data-entry.agent’.
I tend to use this system though only when dealing with projects that data management is the purpose of the site such as; admin system or application. I tend to find that is is those types of projects where the the oocss approach is most applicable because chances are there are many of the same elements being used in a different context even though they have very similar styling throughout.
Either way the approach I use is semantic in terms of distinguishing the context of which a component is being used whether it be a data-grid, data entry form or search filter.
That isn’t oocss. It is unsemantic and mixing presentation w/ structure. There is a really fine line in that what your doing is really no different than applying classes like red, blue, font-size-12, etc. The only difference is your grouping styles together. However, the class names in no way express the semantic nature of structure of the document just how it looks. The difference between that and using classes as I have explained two major points. One point being the class names add application level meaning. The second being when all style for a x entity needs to be changed only the CSS needs to be changed. In contrast with your system the HTML would need to modified and depending the severity it would need to be changed in many places. Either that or nullify the meaning of red to actually be blue (that would be the quickest but completely wrong way).
Spot on.
oocss is a concept, it is not a framework. It is a way to take styling similar elements beyond page detection based on applying application level meaning expressed by classes to common visual concepts used to deliver content and/or functionality to the end user. Getting it right involves identification of those common concepts which can be difficult at times since they will not always be the same. However, when done correctly the concept itself eliminates redundant code and provides an accelerated means of making global style changes with high level of granular control.
The concept is really as simple as this:
<form class="data-entry">
</form>
No none semantic mark-up or anything just applying meaning considering the form element itself does not provide enough information to separate it from all the other “types” of forms that may be getting used on a site. That is really all it is or all I have ever seen it as. To go a step further and create a framework based on commonly used components isn’t the core idea. That is essentially what bootstrap is – the main one that comes to mind.
When there is absolutely no semantic relationship between styling the elements similar practice what ralph.m suggested. Generally those types of styles will be placed in a CSS file establishing the overall look and feel. Where as, styles that affect specific cases/pages will go else where.
Just noticed this thread is over 6 months old…
Off Topic:
Just noticed this thread is over 6 months old…
I unintentionally resurrected this thread.
My post was in answer to a a thread posted today.
Now the site structure seems to be changing and I cannot find the post I was trying to answer.
The point I was trying to make was to reduce the style-sheet.css file size by replacing duplicate fixed elements by a single TLA class.
For example count the number of times background-color: is duplicated in the style sheet.
That new thread is here:
Perhaps the conversation should continue there.