Oop css?

I heard some mumbo jumbo abut Object Oriented CSS, the idea sounded silly to me. Someone please give me at least 2 reasons as to why OOPCSS is a joke. If it is, because to me it seems worthless and uneeded.

Why can’t we just use CSS and be happy? It’s simple enough. Whats the need with trying to over complicate everything. Seems like common best CSS practices are just fine, no need for “OOPCSS”.

You can! No one said you had to use it. :slight_smile:

There are some other threads on this, such as:

@cluongo

I heard some mumbo jumbo abut Object Oriented CSS, the idea sounded silly to me.
Someone please give me at least 2 reasons as to why OOPCSS is a joke. If it is,
because to me it seems worthless and uneeded.

Why can’t we just use CSS and be happy? It’s simple enough. Whats the need with
trying to over complicate everything. Seems like common best CSS practices are
just fine, no need for “OOPCSS”.

Did you mean to say " at least 2 reasons as to why OOPCSS is NOT a joke"?

I reckon that if your toolbox only consists of a hammer then only a single solution is available.

There are quite a few usefult tips in the above link which I think applies to large projects.

@noonnope - http://www.sitepoint.com/forums/showthread.php?742685-Object-oriented-CSS]

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!

What I do not like in a style sheet is duplication.

A TLA class can reduce style-sheet size tremedously.



.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}
.tdn {text-decoration: none}
.w32 {width:32%} .w66 {width:66%}   .w88 {widh:88%}


# Usage:
<div class='w88 mga fs1'>

  <div class='fll w32 bgr fwb'>
     Red - bold text
     <a href='#' class='tdn'> a NOT underlined link</a>
  </div>

  <div class='fll w32 bgg fs2'>
      Green in larger text
  </div>

  <div class='fll w32 bgb'>
      Blue # corrected from a previous post
  </div>

 </div>  

I’ve been thinking about this quite a lot recently.

OOCSS
I like OOCSS. When I first read the slides it made sense, make re-usable components with css, use multiple classes for variations.
Another similar concept is Jonathon Snook’s http://smacss.com/ which I haven’t read yet.

cluongo, flick through the slides or watch the video. If there’s nothing in there you want to use, that’s fine. It’s not a joke though.

CSS classes for Layout
This is quite a different topic to OOCSS, where it overlaps is that both OOCS and layout frameworks encourage you to re-use code without having to write more CSS and to put more presentational classes into the HTML.

I agree semantic markup is important, semantic class names are important too, you should definitely use <p class=“info”> as opposed to <p class=“yellow_info_bar_with_bold_text”></p>

But, layout doesn’t fit nicely into that category.
I find layout is quite often closely tied to the content - often you change the layout to accommodate changes to the content.

For most simple sites where there isn’t a huge amount of variation between layouts you can get away without layout classes.
As the site grows if you don’t have some layout classes then your stylesheet will continue to grow with every slight variation - This is one of the major issues that OOCSS was trying to address.

But it’s not semantic!
It makes no difference to the experience or accessibility of the final page. I’ve stopped caring about this.
People have started hiding the fact that they are tying layout to content by using mixins which just copies floats / widths / gutters into the different selectors.
There’s no presentational classes in their HTML so they feel good about it, it’s just that it’s duplicated on mass throughout the CSS, and it’s only a cover.

Mixins will eventually be available in CSS, so duplication won’t be an issue.

Presentational classes mean that you can’t change the design later on without changing the HTML
That’s true, but that’s not a problem.

With a serious re-design you’re always going to be re-working the content & layout at the same time.
I’ve never had the case where a full redesign didn’t mean shuffling bits of HTML around.

@John_Betong, I have a similar set of classes I stick with my reset, though I object to these three because they are strictly presentational and I can’t think of good reasons for them.


.bgr {background-color:#f00}     .bgg  {background-color:#090}  .bgb  {background-color:#9ff}
.fwb {font-weight:700} 
.tdn {text-decoration: none}

But, to be honest there are cases where I make exceptions to the rule, for special feature buttons I do have classes like “blue-btn”, “red-btn”

Here are my utility classes


.fr { float: right }
.fl { float: left }
.cl { clear: left }
.cr { clear: right }
.cb { clear: both }
.ib { display: inline-block; vertical-align: top }
.clearfix:after {
	content: ".";
	display: block;
	height: 0;
	clear: both;
	visibility: hidden;
}

I have also used fluid grid’s like this. hold the torches and pitchforks


/* layout */
.fluid > div { float: left }
.fluid .quarter { width: 25% }
.fluid .half { width: 50% }
.fluid .third { width: 33% }
.fluid .fourth { width: 25% }
.fluid .fifth { width: 20% }
.fluid .sixth { width: 16.5% }
.fluid .two-thirds { width: 66% }
.fluid .three-fourths { width: 75% }
.fluid .two-fifths { width: 40% }
.fluid .three-fifths { width: 60% }
.fluid .four-fifths { width: 80% }

.fluid .inner { padding-right: 20px }
.fluid > div:last-child > .inner { padding-right: 0 }

@media only screen and (max-width:480px) {
  /* linearize grids under 800px */
  .fluid > div { float: none !important; width: 100% !important }
  .fluid .inner { padding-right: 0 }
}

I’m interested in hearing others opinions on this, I think there’s good reasons for layout classes.
Especially when you use grids extensively.

I don’t think so that OOPCSS is necessary to use you can surely implement the CSS and do whatever you are trying to do. The results will be the same and the browser compatibility will be surely easily resolve through using simple CSS.

I think it sounds like a joke because “object-oriented” refers to actual programming languages (which CSS is not) who have objects (which CSS does not).

That aside, I think Mark’s and John’s comments pretty much answer well why anyone is using “OOCSS” despite the above sentence. The idea of reusing code and modularity sounds sensible to many developers, probably especially those who are doing both programming on the back end and CSS on the front end.

I don’t think he did… though thank you for the STUNNING example of everything WRONG with the whole OOCSS approach pretty much proving that the folks who use it fail to grasp the point of HTML, most of the reasons to use CSS, and on the whole destroying ANY chance of having multiple page targets via the MEDIA attribute since, well… YOUR INLINING PRESENTATION IN THE MARKUP!!!

I particularly enjoyed your use of vague/cryptic class names, and the nonsensical multi-classing which frankly at which point you might as well go back to using HTML 3.2 without CSS for all the ‘improvement’ in coding practices your example offers!

Seriously:


  <div class='fll w32 bgr fwb'>

You might as well go back to using ALIGN, CENTER, and FONT for all the ‘improvement’ that gives you in your markup… and of course the uselessly vague classnames make the code SO easy to maintain.

JUST like most of the CSS framework garbage, OOCSS relies on presentational use of classes – basically saying what things looke like instead of what they are in the markup… It actively encourages just “slapping classes on everything” instead of leveraging inheritance and semantics – which to borrow from Carlin, “Not every ejaculation deserves a name”.

… and thank you for this too:

As it shows the flaw in logic on which OOCSS seems to be based – while certainly keeping the stylesheet size under control is important, MORE important is keeping the HTML size under control; something OOCSS fails to do with all the pointless PRESENTATIONAL classes in the HTML. WHY is that one of the entire reasons to use CSS?

SIMPLE, CSS in an external sheet is cached across pages on a site; HTML is not. The more you can move out of the markup and into the CSS, the more you can pre-cache sub-page appearance, the faster sub-pages will load and the less bandwidth wasted should your site actually manage to do something more than be a ‘one-hit wonder’ in bouncyland.

AND all those presentational classes do not translate AT ALL to media types, media queries… if you’re only styling for desktop ‘screen’ it could work, but that’s NOT the only thing you should be thinking of any time after 1998!!! (or before 1996 – interesting that…)

Which again, this is just another of those “new ideas” like the HTML 5 idiocy that seems more slated to set coding practices back a decade or more than to introduce ANY sort of better coding practice! I pity the nubes too green to realize what total trash it is – which goes hand in hand with the “back end only” PHP coders who haven’t learned enough HTML or CSS to be writing PHP in the first place, or the folks who are STILL basically writing HTML 3.2 and don’t even realize it.

In other words two things that BOTH defeat the point of using CSS in the first place. “layout classes” == presentational nonsense and a failure to grasp the POINT… you’re “utility classes” basically being “how to forget about caching models and piss away all your bandwidth”. “Grids” in their typical deployment relying on presentational classes forgetting that there’s supposed to be more to a website than a “perfect width layout designed for just one media target”.

Your float/clear classes for example – at which point you might as well go back to using the ALIGN and CLEAR attributes for all the ‘improvement’ it offers in the markup – and don’t even get me STARTED about that clearfix NONSENSE begging the question “what is this, 1998?”

Literally, it’s just another of the creations made for people who failed to grasp the entire POINT of HTML STRICT, the entire POINT of separation of presentation from content, and how “desktop screen” is NOT your only target! In other words, the folks who up until recently were vomiting up HTML 3.2 and slapping a tranny doctype on it – today just toss a HTML 5 lip-service on top while still spewing the same outdated coding methodologies we were supposed to start moving away from almost a decade and a half ago!

@deathshadow60

Many thanks for the constructive criticism.

Can you supply a page-link concerning good HTML and CSS practice - preferably one that you have written.

you’re “utility classes” basically being “how to forget about caching models and piss away all your bandwidth”

I find it turns out to be the same or less HTML most of the time.
A common layout is a container with something on the left, something on the right. *This is just an example.

<div class="header">
  <span class="sign-in">
    <a href="#">Sign in</a>
    <a href="#">Create an account</a>
  </span>
  <img src="img/logo.png">
</div>

I might use something like this instead.


<div class="header">
  <span class="fr">
    <a href="#">Sign in</a>
    <a href="#">Create an account</a>
  </span>
  <img src="img/logo.png">
</div>

Your float/clear classes for example – at which point you might as well go back to using the ALIGN and CLEAR attributes for all the ‘improvement’ it offers in the markup – and don’t even get me STARTED about that clearfix NONSENSE begging the question “what is this, 1998?”

There are some cases where the clearfix is preferable to overflow:hidden.
Adding a class is much easier than coding the correct clearfix by hand each time - and less bytes, this is why it’s popular.

Literally, it’s just another of the creations made for people who failed to grasp the entire POINT of HTML STRICT, the entire POINT of separation of presentation from content, and how “desktop screen” is NOT your only target!

No, I understand separation of concerns.
I’ve tried to explain that if layout is important to you, and you like grids, then you have two options - use layout classes, or a heap of custom CSS and re-invention for each page.

Your criticisms are minor and haven’t convinced me to do more unnecessary work for myself.

While I’d be wondering what it needs the span for; as I’d move the image first, float it left and text-align the anchors right… then you only need a class on the outermost container…

NOT that semantically “sign in create an account” as one run-on makes ANY sense since inline-level tags, even anchors, do not change the meaning of the text in flow; so literally you’ve got a run-on sentence… NOT that a logo likely even BELONGS in the HTML… and that outer DIV is probably unnecessary too… I smell a H1, image sandbag span, and a UL there.


<h1>
  Site Title
  <span><!-- image sandbag --></span>
</h1>
<ul class="userMenu">
  <li><a href="#">Sign in</a></li>
  <li><a href="#">Create an account</a></li>
</ul>

Guess it comes down to how you’d go about coding things in the first place. My gut reaction to the markup of your examples is “Too many meaningless containers” and “Not enough semantic meaning”… probably also depends on how you write your markup – thinking “screen layout” before you even have semantic markup, as opposed to making semantic markup and THEN creating the layout – I lean towards the latter as IMHO the former is putting the cart before the horse.

But there’s a reason I can write 90-95% of my markup before I’ve laid down a single line of CSS…

Hell, even with what you have for code, you’ve got a perfectly good outer ID and only one span inside it – what does the span even need a class FOR either way of doing it?!? Again, like Carlin said about abortion, not every ejaculation deserves a name… so not every tag that’s getting style applied should have a class thrown at it for nothing. That’s the same thing as wordpress’ idiotic “menu-item” class or where you see people do this nonsense all the time:


<div class="nav">
	<ul class="navUl">
		<li class="navLI"><a class="navA" title="Home">Home</a></li>
		<li class="navLI"><a class="navA" title="Forums">Forums</a></li>
		<li class="navLI"><a class="navA" title="Links">Links</a></li>
		<li class="navLI"><a class="navA" title="Contact Us">Contact Us</a></li>
	</ul>
</div>

Which if you don’t know what’s wrong with that, you probably shouldn’t be writing HTML in the first place :smiley: (yes wordpress developers, I’m looking at YOU!)

I used to have a few good ones written by Dan Schulz, but with his passing they’ve gone off into la-la land. Most of my good stuff was forum posts (back read a few of my ‘helping’ others here in the CSS area – some of them are close to full blown tutorials).

Wait… There’s this… it’s a rough draft of a tutorial co-written by Dan for a website we were going to launch – said site has languished unfinished since his passing. He was the idea guy and the one who kept projects on track; I was the technical and standards guy…

It’s a very rough draft thrown into a quicky layout, it’s also three or four years out of date on content (like referencing Ian’s starter book, which with 3rd edition gushing all over itself with HTML 5 like some creepy German shaiza video… not so much) and not all the links are working, but it’s a starting point for insights into where I’m coming from with my approaches.

http://www.cutcodedown.com/preview/

The entire idea for the finished product being to show how to make the markup, THEN the layout, THEN hang the goofy graphics on it… taking this:
http://www.cutcodedown.com/preview/lesson1/template.html

plugging in content semantically:
http://www.cutcodedown.com/preview/lesson2/template.html

applying the layout with CSS:
http://www.cutcodedown.com/preview/lesson3/template.html

and then the chapter that never got written, hanging the graphics on it, throwing in some min-width, etc…
http://www.cutcodedown.com/preview/lesson4/template.html

Unfortunately with everyone just pissing out websites any old way and having ZERO interest in doing anything better, the PSD jockeys pissing all over the Internet as a whole, the Javascripttards blowing hundreds of K of javascript on little more than goofy half-assed animations, my disgust with the industry as a whole has not only made me abandon most of my Internet projects due to being sick of feeling like Don Quixote, it’s made the entire Internet less useful as a tool for me than it was a decade ago.

… which combined with not having Dan keeping my energy up on the topic, is probably why I’m dialing back my involvement in just about everything modern and going back to my retrocomputing hobby instead… Back when there was at least SOME pride in one’s code.

If I were to finish it and update it for today, I’d probably have it use CSS3 for much of the effects handled using images, give example code for using media queries for multiple targets, add massive warnings about the complete idiotic BS that is HTML 5, probably have to add a beginner tutorial since there’s currently no “on shelf” sources that are worth a flying purple fish, get rid of the LI that Dan talked me into wrapping the articles with (since IMHO the moment you have a heading it’s no longer a list item), etc, etc…

I’ve tried to explain that if layout is important to you, and you like grids…

Neither visual design or layout is important to you, so I don’t expect to convince you to stop duplicating your css.

ds, have you ever added a div, span, class or id to your HTML?
None of those have any semantic meaning whatsover, if you’ve done that then you’ve littered your pristine HTML with meaningless garbage only intended for presentation.

The web is primarily a visual medium,
To 99% of your users, what the see is what they get.

The visual representation of the site is paramount, I agree semantic markup and good class names are important too.
You seem to be more concerned with HTML that satisfies you, as opposed to HTML that satisfies those you’re creating content for.

without saying WHAT that presentation IS… and that’s the difference; meaning it can be any presentation for whatever media types I’m targeting… I might say “div#sideBarWrapper”, with “div#firstSideBar” and “div#secondSideBar” inside it, sibling to div#content – but I’m not saying HOW I’m presenting that sidebar meaning I can display:none it for print if it’s navigation and adverts, I can make the entire layout a single column on sub 320px width displays, a two column layout on middle-widths, and three columns for really big displays – while also being semi-fluid within it’s ranges. Let’s see some “CSS Framework” like that grid idiocy do that!

As opposed to using presentational classes that by definition ‘lock’ you into that style… you’re saying ‘left’,‘right’,‘clear’ when you might not want that behavior for all targets – Sure, it’s primarily a visual medium, but for what media? Handhelds? Tablets? Netbooks? Print? 2056x1536 desktops?

The correct answer should be “all of the above” – the entire original point of HTML, the entire reason the MEDIA attribute exists on links, and the entire reason for the introduction of MEDIA queries in CSS3. Truly well crafted markup and style should be able to adapt to all of those – that’s what HTML was supposed to be for, why there’s a MEDIA attribute, and why CSS3 is giving us SO many tools to actually go out and do it.

… and again, if you’re going to say “left”, “right”, “clear” or even worse nonsense like “red” or “smallFont” – why are you even using CSS in the first place? That may as well be HTML 3.2 for all the good it does you.

But sure, let’s keep crapping out ‘pretty pictures’ that are actually USELESS as websites, waste bandwidth for nothing, don’t gracefully degrade, don’t work well with screen readers treating your entire content as a giant run-on sentence instead of actually using the tools made available to us for delivering content to everyone.

As opposed to using presentational classes that by definition ‘lock’ you into that style. Sure, it’s primarily a visual medium, but for what media? Handhelds? Tablets? Netbooks? Print? 2056x1536 desktops?

The correct answer should be “all of the above” – the entire original point of HTML, the entire reason the MEDIA attribute exists on links, and the entire reason for the introduction of MEDIA queries in CSS3. Truly well crafted markup and style should be able to adapt to all of those – that’s what HTML was supposed to be for, why there’s a MEDIA attribute, and why CSS3 is giving us SO many tools to actually go out and do it.

You take it too far…
My fluid grid example linearises on small screens.

But sure, let’s keep crapping out ‘pretty pictures’ that are actually USELESS as websites, waste bandwidth for nothing, don’t gracefully degrade, don’t work well with screen readers treating your entire content as a giant run-on sentence instead of actually using the tools made available to us for delivering content to everyone.

We were talking about layout classes. This has nothing to do with gracefully degradation or screen readers.

Do you have an example of that? I’ve not once seen ‘grids’ that were fluid, much less were anything less than a total disaster on different screen sizes… at least not without some form of bizarre/broken looking float drop.

Has everything to do with it when it’s one of the reasons NOT to use it… since it prevents you from leveraging most of the tools for doing it!

Do you have an example of that? I’ve not once seen ‘grids’ that were fluid, much less were anything less than a total disaster on different screen sizes… at least not without some form of bizarre/broken looking float drop.

Submitting even the simplest code to you is an ordeal, you take too much liberty in trashing everything presented to you… but I’ll play along.
It’s just a simple fluid grid that linearises at a certain point.


<!doctype html>
<html>
<head>
<style>
.clearfix:after {
	content: ".";
	display: block;
	height: 0;
	clear: both;
	visibility: hidden;
}
.fluid > div { float: left }
.fluid .half { width: 50% }
.fluid .third { width: 33% }
.fluid .fourth { width: 25% }
.fluid .fifth { width: 20% }
.fluid .sixth { width: 16.5% }
.fluid .two-thirds { width: 66% }
.fluid .three-fourths { width: 75% }
.fluid .two-fifths { width: 40% }
.fluid .three-fifths { width: 60% }
.fluid .four-fifths { width: 80% }

.fluid .inner { padding-right: 20px }
.fluid > div:last-child > .inner { padding-right: 0 }

@media only screen and (max-width:480px) {
	.fluid > div { float: none !important; width: 100% !important }
	.fluid .inner { padding-right: 0 }
}
</style>
</head>
<body>
<div class="fluid clearfix">
	<div class="half">
		<div class="inner">
			<p>half</p>
		</div>
	</div>
	<div class="half">
		<div class="inner">
			<p>half</p>
		</div>
	</div>
</div>

<div class="fluid clearfix">
	<div class="third">
		<div class="inner">
			<p>third</p>
		</div>
	</div>
	<div class="third">
		<div class="inner">
			<p>third</p>
		</div>
	</div>
	<div class="third">
		<div class="inner">
			<p>third</p>
		</div>
	</div>
</div>

<div class="fluid clearfix">
	<div class="fourth">
		<div class="inner">
			<p>fourth</p>
		</div>
	</div>
	<div class="fourth">
		<div class="inner">
			<p>fourth</p>
		</div>
	</div>
	<div class="fourth">
		<div class="inner">
			<p>fourth</p>
		</div>
	</div>
	<div class="fourth">
		<div class="inner">
			<p>fourth</p>
		</div>
	</div>
</div>

<div class="fluid clearfix">
	<div class="fourth">
		<div class="inner">
			<p>fourth</p>
		</div>
	</div>
	<div class="three-fourths">
		<div class="inner">
			<p>three-fourths</p>
		</div>
	</div>
</div>

<div class="fluid clearfix">
	<div class="fifth">
		<div class="inner">
			<p>fifth</p>
		</div>
	</div>
	<div class="fifth">
		<div class="inner">
			<p>fifth</p>
		</div>
	</div>
	<div class="fifth">
		<div class="inner">
			<p>fifth</p>
		</div>
	</div>
	<div class="fifth">
		<div class="inner">
			<p>fifth</p>
		</div>
	</div>
	<div class="fifth">
		<div class="inner">
			<p>fifth</p>
		</div>
	</div>
</div>
</body>
</html>

The only reason I raised this at all was because you were ranting that your presentational classes can’t adapt to screen sizes.

A more thorough example is bootstrap from twitter.
http://twitter.github.com/bootstrap/

I’m sure you’ll take pride in trashing that too but there’s no reason for it.
I like OOCSS and I’ve come around to acknowledging the place of layout frameworks like 960 and blueprint. They work well.

@deathshadow60

Many thanks for the constructive criticism.

Can you supply a page-link concerning good HTML and CSS practice - preferably one that you have written.

So that would be a no?

That’s not fair, Jason has spent a lot of time contributing his views on best practice, just search the forums for his posts if you want to understand them.
He’s also linked to examples above.

I there anyone else who has started using unsemantic classes for grids or am I the only backslider? :wink:
Or do most people simply not use grids for layout?

Lots of people do it – doesn’t make it good practice.

Really though the mere concept of grids just runs contrary to building HTML for what HTML is for – you can use those widths, but you shouldn’t be saying them in the markup; markup is for what things ARE, not how they appear.

Your example up above is NOT what I’m used to thinking of when I hear ‘grids’ – that’s percentage fluid layout, not grid based. I can see how it might appeal to some, but it would need a LOT more media targets and all those extra ‘inner’ div would drive me nutters (solution, pad/margin the content instead). It also has the problem of uneven padding/margins since it’s only got one side padded, but that too would be easy enough to ‘fix’.

Really all those identical classes and the lack of being able to say “Make JUST this 100%, just this 50%” from the CSS instead of the markup would drive me nutters and be ‘unsustainable’ when working with a site in the long term. I mean what if I want to make those “fifths” 50% and margin:auto the last? What if I want to make the ‘three-forths’ be auto with the forth fixed without messing up every other element that uses those classes on the same page?

I guess that’s the biggest failing I see with OOCSS – what most people consider an advantage; being able to set everything in one spot, is a disadvantage to me as “I want to change just one thing” without screwing up everything else – and that means digging into the HTML to swap out that class or adding an ID – at which point why not just have an ID/classs and group ID/classes that share really common properties together?

Though I think that goes with the whole routine where people are writing their layout before they have semantic content… it’s fun to play with, but the resulting sites often have MAJOR usability issues. Even when I use those pesky extra DIV, I do so to group like elements together, often so I can have single ID or class hooks to style the semantic child elements…

for example:

<div class=“subSection”>
<h2>Title</h2>
<p>Some Text</p>
</div>

.subSection {float:left; width:320px; display:inline; margin-right:1em; background:#DEF; border:4px solid #008}
.subSection h2 {padding:0.2em 0.5em; background:#008}
.subSection p {padding-bottom:1em}

Your OOCSS folks would do what???

<div class=“floatLeft320 brightbackground darkborder”>
<h2 class=“inverse lightpadded”>Title</h2>
<p class=“bottomPaddedOnly”>Some Text</p>
</div>

I mean, that’s basically the difference we’re talking about – and exactly why OOCSS is rubbish to me… EVERY time I see child classes used in the ‘OOCSS’ manner like that I kneejerk into “You’ve got a perfectly good outer wrapper and semantic tags, what in blazes do you need child classes for?!?”

Of course, what I’m generally seeing OOCSS folks doing is:

<div class=“floatLeft320 brightbackground darkborder”>
<p class=“header inverse lightpadded”>Title</p>
<p class=“bottomPaddedOnly paragraph”>Some Text</p>
</div>

Which is just time to drag out the pimp slap. I swear, next person I come across doing <td class=“header”>, <p class=“header”> or the all-time popular <td colspan=“5” class=“title”><strong> is getting a backhand.