portfolio
services
design
DESIGN

We have many talents aside from web site work!

Our design team can help you with

all of your company or personal branding needs.
  • logos
  • branding material
  • stationery
  • posters
  • business cards
  • brochures
  • manuals
  • book covers
  • custom book binding
  • photography
  • videography
design
marketing
MARKETING

We offer marketing solutions for your business!

We can create a marketing strategy to suit your needs and to reach your target audience. We offer help with

  • social media
  • print
  • sinage
  • posters
  • creative concepts
  • brochures
marketing
branding
BRANDING

We can build a branding package for your business! Why is good branding important?

GOOD branding will ...

  • deliver your message clearly
  • confirm your credibility
  • connect your target prospects emotionally
  • motivate the buyer
  • concrete user loyalty
branding
web sites
WEB SITES

Do you need a website?

We can design and build a website, or update your existing site to suit your changing business needs.

We build web and mobile solutions on the cutting edge of modern technology

Our developers, designers and engineers deliver clean, high performance applications on time, and on budget.

We offer personable, professional training for the solutions we build.

We offer FREE analysis and quotes

web sites
SEO
SEO

Search Engine Optimization - SEO

Our SEO experts can increase your online visibility, get your more customers, and improve your BOTTOM LINE.

Do you have a GREAT website that no one sees?

We achieve high ranking results using only White-hat (ethical) techniques.

We always keep our clients up to date with analytics and overall progress.

Contact us for a FREE analysis and quote.

 
seo
about
We do all things web and branding. We do not do laundry.
We are based in Decatur, GA, but we serve clients worldwide. We can sometimes be found in Dekalb Farmer's Market watching the fish in the big tanks.
Patrick is our tech guy, and co owner. His finest moment was when he was 4 years old, his Mom dressed him up like a smurf. He looked so real, he made the other kids in preschool cry.
John is our other tech guy, and co owner. He has a love hate relationship with Home Depot, and enjoys cutting vegetables.
DeAnna, our designer and co owner who loves her new spoon rest, and has a penchant for antique dishes. It is rumored that she does not believe in gravity.
blog
Today's Date
August 18, 2017

Thoughts on Object Oriented CSS

Posted on  
   /  by    Patrick

If content is King then performance is Queen. In today’s world of insanely fast internet connections, the effects of spaghetti code on load times are becoming increasingly more noticeable. There are developers whose entire career is built on refactoring code for better performance. You hear about this type of work often in the realm of Javascript, PHP or Ruby but it’s often overlooked when dealing with CSS. Bloated CSS is less expensive than a bloated JavaScript function at load time. If you’re trying to write code that’s easier to maintain and helps you gain milliseconds you might want to have a look at Object Oriented CSS. 

As with any object based coding method the goal of OOCSS is to encourage code reuse and stylesheets that load faster. You can check out the OOCSS github wiki here. It outlines the 2 main principles:

1.) Seperating the Structural Elements from the Skin

Most visible elements within a styled HTML document have varying visual features that are re-used in different contexts. Think colors, fonts, etc… Likewise the block level elements or structural pieces are also re-used. When these different elements are abstracted into classes they become reusable with less code. Let’s compare some code so you can see what this might look like:


#tab {
width: 200px;
height: 50px;
padding: 10px;
border: solid 1px #ccc;
background: linear-gradient(#ccc, #222);
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

#container {
width: 400px;
overflow: hidden;
border: solid 1px #ccc;
background: linear-gradient(#ccc, #222);
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

#thingy {
width: 500px;
min-height: 200px;
overflow: auto;
border: solid 1px #ccc;
background: linear-gradient(#ccc, #222);
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

The three elements you see here have different styles all applied using the non-reusable id selector. If we reassess this code a bit we find that they have properties in common. We can abstract the common styles to get to something like this:


.tab {
width: 200px;
height: 50px;
}


.thingy {
width: 500px;
min-height: 200px;
overflow: auto;
}


.visual {
border: solid 1px #ccc;
background: linear-gradient(#ccc, #222);
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

Now these examples are using classes and we’re cooking with fire. The common styles are thrown into one “visual,” class that can be applied over and over again without rewriting the same code. As you know classes can be called within a block level element in order of inheritance like: <div class=”thingy visual”></div>

2.) Seperation of Content from the Container Elements

This seems like a pretty straight forward concept but let’s take a moment to illustrate why this might be important.


#thingy h3 {
font-family: Arial,
Helvetica, sans-serif;
font-size: .8em;
line-height: 1;
color: #777;
text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}

Now here any 3rd level headers that are children of the #thingy element will inherit these styles. But what if I want to call identical styles with a couple of changes in the footer? Then we would need something like this:


#thingy h3, #footer h3 {
font-family: Arial, Helvetica, sans-serif;
font-size: 2em;
line-height: 1;
color: #777;
text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px; }

#footer h3 {
font-size: 1.5em;
text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;
}

Or even worse:


#thingy h3 {
font-family: Arial, Helvetica, sans-serif;
font-size: 2em;
line-height: 1;
color: #777;
text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}

/* other styles here.... */

#footer h3 {
font-family: Arial, Helvetica, sans-serif;
font-size: 1.5em;
line-height: 1; color: #777;
text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;
}

Now we’re really duplicating code that could be written once… sheesh — it’s like a unicorn exploded repeatedly!! With OOCS we’re encouraged to analyze this a bit deeper and if we enact these best practices guess what… we get better load times! and code that’s easier to manage.

The styles that are declared using the descendant selector in those above examples are not reusable, because they are dependent on a particular container (in this case either the sidebar or the footer).

When we use OOCS’s class based model we ensure that our styles are not dependant on any single containing element and we are free to use them anywhere within our documents regardless of structure.

This new way of approaching CSS begs the question — well why not just abandon using IDs for block level elements? and.. Can’t that cause new problems for DOM applications that rely on hash events ?? These are good questions to which I reply: You can use IDs in tandem with classes! In some cases it’s a good idea to have both — just don’t build your styles using IDs as selectors.

CONCLUSION:

Utilizing OOCS is easy and the benefit is great. Remember to avoid using descendant selectors. Don’t use IDs as hooks for styling. Avoid attaching classes to elements like div.thingy or h1.title when at all possible. Use GRIDS .

Go Forth — and refactor!

Leave a Reply

Your email address will not be published. Required fields are marked *