<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Object Oriented CSS (OOCSS): The Lowdown</title>
	<atom:link href="http://www.typesett.com/2010/01/object-oriented-css-oocss-the-lowdown/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.typesett.com/2010/01/object-oriented-css-oocss-the-lowdown/</link>
	<description>Your AMUSING Resource for Useful Design, Typography and Web Dev Articles</description>
	<lastBuildDate>Mon, 05 Apr 2010 18:46:48 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Bleak</title>
		<link>http://www.typesett.com/2010/01/object-oriented-css-oocss-the-lowdown/comment-page-1/#comment-980</link>
		<dc:creator>Bleak</dc:creator>
		<pubDate>Sun, 04 Apr 2010 22:11:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.typesett.com/?p=1136#comment-980</guid>
		<description>I can&#039;t say I&#039;m overly convinced at this technique.
It really just seems like someone&#039;s personal take on how they choose to organise CSS.
&#039;Best Practice&#039; is still fairly subjective.</description>
		<content:encoded><![CDATA[<p>I can&#8217;t say I&#8217;m overly convinced at this technique.<br />
It really just seems like someone&#8217;s personal take on how they choose to organise CSS.<br />
&#8216;Best Practice&#8217; is still fairly subjective.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Auré</title>
		<link>http://www.typesett.com/2010/01/object-oriented-css-oocss-the-lowdown/comment-page-1/#comment-935</link>
		<dc:creator>Auré</dc:creator>
		<pubDate>Sun, 14 Mar 2010 12:15:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.typesett.com/?p=1136#comment-935</guid>
		<description>Interresting article!</description>
		<content:encoded><![CDATA[<p>Interresting article!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: alex@jkjhkj</title>
		<link>http://www.typesett.com/2010/01/object-oriented-css-oocss-the-lowdown/comment-page-1/#comment-843</link>
		<dc:creator>alex@jkjhkj</dc:creator>
		<pubDate>Wed, 13 Jan 2010 08:09:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.typesett.com/?p=1136#comment-843</guid>
		<description>@Phil: thanks for adding it to us. It really worth enough to know about it. 
@TypeSett: thanks also for the code. You&#039;re right, it is easy to understand than just using acronyms.</description>
		<content:encoded><![CDATA[<p>@Phil: thanks for adding it to us. It really worth enough to know about it.<br />
@TypeSett: thanks also for the code. You&#8217;re right, it is easy to understand than just using acronyms.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anne</title>
		<link>http://www.typesett.com/2010/01/object-oriented-css-oocss-the-lowdown/comment-page-1/#comment-835</link>
		<dc:creator>Anne</dc:creator>
		<pubDate>Sat, 09 Jan 2010 23:28:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.typesett.com/?p=1136#comment-835</guid>
		<description>Interesting read. I&#039;m all for efficiency and cleaner code, thanks for sharing.</description>
		<content:encoded><![CDATA[<p>Interesting read. I&#8217;m all for efficiency and cleaner code, thanks for sharing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TypeSett</title>
		<link>http://www.typesett.com/2010/01/object-oriented-css-oocss-the-lowdown/comment-page-1/#comment-829</link>
		<dc:creator>TypeSett</dc:creator>
		<pubDate>Thu, 07 Jan 2010 19:01:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.typesett.com/?p=1136#comment-829</guid>
		<description>@Phil — Thanks for commenting. It&#039;s great to see how other people approach their work. My only thing is that naming it rather than using a acronym can sometimes be more semantic... easier to understand/train. Thanks, Phil!</description>
		<content:encoded><![CDATA[<p>@Phil — Thanks for commenting. It&#8217;s great to see how other people approach their work. My only thing is that naming it rather than using a acronym can sometimes be more semantic&#8230; easier to understand/train. Thanks, Phil!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil Ricketts</title>
		<link>http://www.typesett.com/2010/01/object-oriented-css-oocss-the-lowdown/comment-page-1/#comment-827</link>
		<dc:creator>Phil Ricketts</dc:creator>
		<pubDate>Thu, 07 Jan 2010 09:15:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.typesett.com/?p=1136#comment-827</guid>
		<description>Good tips in here, nice to see that I follow most of them. 

Though I do something that some might frown upon: I use short ID/classes like this:

Main content areas (structure):
#h = Header
#c = Content
#f = Footer
#z = extra (progressive enrichment markup, modernizr test etc)

For modules (structure):
.c = content
.h = header
.f = footer

Generic stuff (for article content  &amp; some structure):
.clr = clear
.fl = float left
.fr = float right
.tl = text align left
.tr = text align right
.tc = text align center

The logic in this, is that I&#039;m keeping short-length IDs and classes for the structural kinda stuff, and use longer more human-readable classes for definition of content area (e.g. &lt;a title=&quot;Logo innit!&quot; rel=&quot;nofollow&quot;&gt;Logo title&lt;/a&gt;).

I also tend to put the longer human-readable class at the start of the class attribute (e.g. class=&quot;foobar fl tr&quot;).

Having shorter classes for generic kinda stuff, and for main structural markup makes life easier for me as my code is more readable. It&#039;s working for me so far at least!

Thanks for sharing, Nicole.</description>
		<content:encoded><![CDATA[<p>Good tips in here, nice to see that I follow most of them. </p>
<p>Though I do something that some might frown upon: I use short ID/classes like this:</p>
<p>Main content areas (structure):<br />
#h = Header<br />
#c = Content<br />
#f = Footer<br />
#z = extra (progressive enrichment markup, modernizr test etc)</p>
<p>For modules (structure):<br />
.c = content<br />
.h = header<br />
.f = footer</p>
<p>Generic stuff (for article content  &amp; some structure):<br />
.clr = clear<br />
.fl = float left<br />
.fr = float right<br />
.tl = text align left<br />
.tr = text align right<br />
.tc = text align center</p>
<p>The logic in this, is that I&#8217;m keeping short-length IDs and classes for the structural kinda stuff, and use longer more human-readable classes for definition of content area (e.g. <a title="Logo innit!" rel="nofollow">Logo title</a>).</p>
<p>I also tend to put the longer human-readable class at the start of the class attribute (e.g. class=&#8221;foobar fl tr&#8221;).</p>
<p>Having shorter classes for generic kinda stuff, and for main structural markup makes life easier for me as my code is more readable. It&#8217;s working for me so far at least!</p>
<p>Thanks for sharing, Nicole.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
