對象類似Java中的類，保持著OO的特征。
一個CSS對象由4部分組成：
這可能令人費解，因為每個CSS class不是其自身必要的對象，但可以是一個wrapper class的一個部件。比如：
<div class="mod">
<div class="inner">
<div class="hd">Block Head</div>
<div class="bd">Block Body</div>
<div class="ft">Block Foot</div>
</div>
</div>對象是一個class為mod的模塊。包括4個部件節點（不能獨立於模塊外，包括2個區塊，inner和body，和兩個可選擇的區塊，head和foot）
OOCSS具有雙倍的性能優勢：
當你在同一頁面（或者同一站點同時緩存良好）復用一個對象時，這是性能的“免費贈品”。用ID來寫樣式在同一頁面中只能使用一次。@cgrIEgo (twitter)
拿它與singletons比較過，我認為非常精確。可能有些情況下你要用ID定義樣式，比如非常特殊的 header menus，此時你可以在用ID來沙箱（譯注：動名詞）特殊元素並確保此處的代碼不會影響站點的其它地方。選擇ID而非class前要三思，隨著站點的發展，真的很難預料其他人會怎麼處理依據你的CSS所構建的Html。如有選擇的余地，盡可能的考慮擴展性。
我正在考慮移除模板head, body, foot中的ID。某些人或許有多個主區域。站點的多個header 和 footer更難以猜測，但我敢打賭肯定有設計師會這樣想，所以ID很可能會消失（不太順，看原文：Someone
could have multiple main content areas. Multiple site headers and footers are more
difficult to imagine, but I bet there is a designer who can dream up something like
that, so the IDs are very likely to disappear.）。
另一方面，ID hooks are great for linking。放在Html中，不過別用它們來寫樣式。
是的，設計師出於本能理解對象，比多數人當前書寫CSS的方式要形象 — layers of exceptions (想一下，一個老太太吞了一只蒼蠅)。事實上，他們愛上OOCSS的原因有兩個：
設計師是聰明D。我們要給他們信任。他們會講一種不同的，非工程師的語言，但是極客的語言經常以一種丑陋的方式來拒絕人。我們能做的更好。
作為架構師，你應該寫結構對象；圓角如何創建，為角或其他特性放置表象元素，並處理浏覽器差異。新手為這些模塊寫皮膚（borders, colors, background
images, 等等）。
我用OO-CSS方式創建了大批站點（千級的頁面，百萬級的訪問者）。正確的完成後，很好擴展，這意味著新手將處理的個別元件可預見性很強。代碼審閱很容易，因為有可接受的方法明確的規則來擴展對象。這種回饋使新開發者快速生產。
我在FullSIX（一個法國的網絡營銷機構）管理一個前端開發團隊，是我工作過的最有才能的。某些時候我們的成功意味著我們將會有更多難以把控的工作。雇傭前端專家非常困難（沒有這種學校！），所以我開始對一些對寫代碼有興趣的設計師（很少或沒有經驗）推行一個內部實習項目，一個月就可以作為團隊的初級成員工作。
他們的代碼在一個客戶的網站上，同資深開發者寫的一樣好，或許更好因為他們還未學到一些壞習慣:)
3個文件，librarIEs.css (reset 及 fonts 取自 yui), grids.css 及 template.CSS 已完成，其它的還非常不穩定。
注意CSS文件在不斷改進中，我會依據接到的反饋進行改變。
我把CSS文件分為了模塊，比如柵格和模板。在使用時移除不必要的注釋並減少HTTP請求，否則站點會超級慢。這意味著要合並CSS文件為一個稍大的文件。我通過嵌套的注釋來組織CSS。最後，作為上線/部署的一部分，用CSS壓縮器來移除注釋.
我不會修改grids, template, 或者 librarIEs。大量測試表明這些已恰到好處。如果要自定義，考慮下面的擴展基本對象。
獲取你會想要修改content.CSS。去吧，改顏色，字體大小，大小寫。只需注意這個文件在快速發展，同時我還沒有任何文檔來說明如何正確的處理。我會這麼做，我保證。
如果需要不只6中標題樣式，通過添加一個新class來擴展標題對象。
.category{font-size:108%; font-weight:normal; font-style: normal; text-transform:uppercase; color: #333;}
不要這樣做：
#mySaleModule h2, #mySaleModule .h2{font-size:108%; font-weight:normal; font-style: normal; text-transform:uppercase; color: #333;}
如果要擴展對象，比如一個160px的左列，而非默認值，你可以再列上增加額外的class。
<div class="leftCol gMail"> ... </div>
如果默認值和擴展的列寬或者頁面不適合你的站點，你可以擴展列來實現自定義的寬度。
myColumn 擴展列對象來實現自定義列寬。
.myColumn{width:400px;}
Html
<div class="leftCol myColumn"> ... </div>
不要通過重寫我的class來實現，而應擴展此框架提供的對象。我提供了列，標題及其他對象。你可以通過增加另外的class（只指定與我的基本對象的不同點）來擴展這些對象。相對而言此處混合比較好。
不要這樣做（因為更新我的框架時會有些麻煩）：
.leftCol{… 此處自定義CSS …}
當然。移除對象或擴展對象非常合理。只需注意在站點發展時，很難預料到其他人用你的CSS創建的什麼樣的Html。過早優化很危險。
在OOCSS中，一個重要的目標是所有的頁面創建自一個模板。這簡化了CMS開發，因為有一個單獨的起始點所有頁面可以制作為其他的頁面。CMS的用戶不會落入已創建的頁面不能變種為不同的頁面類型的陷阱。OO模板的另一個目標是每一個section（列，header等）控制自己。實際上，這意味著如果要在模板上增加一個左列，只需在Html中增加此列。你從來不想這樣寫CSS吧，為了使子元素滿足表現而DOM樹需要很多改變。對CMS開發來說DOM循環相當的昂貴。
OOCSS可以寫得有語義也可無語義，取決於你創建模塊時用 errorMod 而非 bigRedModule。我選擇class名優一些原則（排名不分先後）：
在大量框架的生態系統中，YUI是專業性及可擴展性的一例。我同他們進行了對比，因為我不斷受到他們代碼和文檔的影響。OOCSS不是一個真正意義上的框架，盡管我創建了很多例子，而是一種書寫可擴展，健壯，可維護性強的CSS的一種方式。也許最好的比喻是一個新的語言。最終，它是未知的JavaScript庫（it
is JavaScript library agnostic），我希望貢獻代碼回YUI及其他框架。
每需要一個隨機數字都要寫一個數字class嗎？
CSS is hard,
not because it is broken , but because it is a legitimate technology requiring
expertise to architect correctly. 為每個站點重復發明輪子非常的愚蠢。
我早期工作過的站點有更標准的模板結構，body上有一個極好的class，依靠這個模板顯示或隱藏左右列。自定義CMS的用戶要創建一個3列布局的頁面時非常沮喪，發現需要兩列，找到它們不得不一個個從頭開始，因為有多個模板/起始點。你或許注意到主列是個流體列，在左右兩列渲染後自適應剩余的空間。
我更喜歡標簽排序勝過視覺排序（因為如果標簽順序改變會變得非常怪異），但是我也只想要一個模板。在web開發中經常遇到的是，兩個重要的目標發生了沖突，我做判斷如何解決。這種情況下標簽排序滿足視覺順序除了右列。在當前的代碼中，只需在Html增加一個左或右列，沒有別處昂貴的DOM變化。
屏幕閱讀器用戶有兩個選擇：
我的意見是對於跳過菜單這兩種方式足夠了。
每個人似乎都有一個回復觀點：SEO，它們都不同，甚至相反。:)基於這個思潮，我傾向於：尤其對含有一定合理數量鏈接的導航菜單，不用太過在意。曾幾何時，我看到過導航鏈接被索引在搜索結果的內容部分，不過是在幾年前了。搜索爬蟲非常智能，我已經准備好想當然的認為如果我以語義化，干淨的方式標記內容，並非填充一坨垃圾鏈接，爬蟲能區分的出來。
把導航菜單標記為列表，允許屏幕閱讀器用戶跳過，並提供“跳至內容”鏈接，對可訪問性提供了雙倍的備用措施。
很顯然，首先考慮的是盡可能少和長遠。
我認為我的選擇有助於減少hack的總體數量，提升性能，並只有忽略不計的風險。話說回來，如果覺得代碼中的_令你作嘔，你完全可以移至單獨的文件。
不會，幸運的是屏幕閱讀器會忽略空的b標簽。使用這個表象標簽（b是加粗）來實現表象具有優勢。這個標簽可以通過服務器端腳本包含，以至於有一天所有的CSS圓角和陰影都支持了，可以關閉腳本並擁有漂亮，干淨，語義化的Html。
不使用派生選擇器沒什麼阻礙，只是把它們放在更高的DOM樹而已。避免在body或頁面中最外層的div放置wide-net class或id，然後對對象產生的變量寫大量的樣式。這不能復用，同時會使頁面渲染變慢。相反，通過直接在對象上添加一個class來增加一個多余的“local”變量（並對其子元素寫派生樣式）。
一個好的經驗是一個容器主體（body of a container）內的任意元素顯然是一個單獨的對象。
這無可厚非，因為UL顯然是一個單獨的對象：
#sidebar ul { ... }
因此，carousel顯然不是body對象的一部分：
body.browseProducts .carousel
這是適當的層疊應用，因為子節點真正的是較大的父對象的一部分。b（角）和inner顯然隸屬於moudle，它們不能獨立存在：
.myModule { ... }
.myModule b { ... }
.myModule .inner { ... }
最好的方法是涉足其中，開始使用代碼（librarIEs, grids, fonts）並提交
bug 報告及功能需求。 我建了一個
OOCSS google group 來進行超過140個twitter字符的討論。
OOCSS的官方站點為 http://ooCSS.org/，有一些例子及下載等。