原文：http://wiki.github.com/stubbornella/oocss/faq（翻譯時為version 28）
翻譯：ytzong
在oocss中怎么定義“對象”？
對象類似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如何提升性能？
oocss具有雙倍的性能優勢：
要用id來對內容寫樣式嗎？
當你在同一頁面（或者同一站點同時緩存良好）復用一個對象時，這是性能的“免費贈品”。用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中，不過別用它們來寫樣式。
|||
設計師可以寫oocss嗎？
是的，設計師出于本能理解對象，比多數人當前書寫css的方式要形象 — layers of exceptions (想一下，一個老太太吞了一只蒼蠅)。事實上，他們愛上oocss的原因有兩個：
設計師是聰明d。我們要給他們信任。他們會講一種不同的，非工程師的語言，但是極客的語言經常以一種丑陋的方式來拒絕人。我們能做的更好。
我是個前端架構師，如何向團隊傳授oocss？
作為架構師，你應該寫結構對象；圓角如何創建，為角或其他特性放置表象元素，并處理瀏覽器差異。新手為這些模塊寫皮膚（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？
獲取你會想要修改content.css。去吧，改顏色，字體大小，大小寫。只需注意這個文件在快速發展，同時我還沒有任何文檔來說明如何正確的處理。我會這么做，我保證。
我需要不只6種標題（h1~h6），如何增加？
如果需要不只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 …}
沒有用到的樣式。我的站點沒有160px的gmail式的列，可以移除嗎？
當然。移除對象或擴展對象非常合理。只需注意在站點發展時，很難預料到其他人用你的css創建的什么樣的html。過早優化很危險。
|||
為什么有一個單獨的模板？
在oocss中，一個重要的目標是所有的頁面創建自一個模板。這簡化了cms開發，因為有一個單獨的起始點所有頁面可以制作為其他的頁面。cms的用戶不會落入已創建的頁面不能變種為不同的頁面類型的陷阱。oo模板的另一個目標是每一個section（列，header等）控制自己。實際上，這意味著如果要在模板上增加一個左列，只需在html中增加此列。你從來不想這樣寫css吧，為了使子元素滿足表現而dom樹需要很多改變。對cms開發來說dom循環相當的昂貴。
這有語義嗎？我要終止像 .formyellow 或 tinyblueh2 的class命名嗎？
oocss可以寫得有語義也可無語義，取決于你創建模塊時用 errormod 而非 bigredmodule。我選擇class名優一些原則（排名不分先后）：
其它的框架如何？這只能同yui一起使用嗎？
在大量框架的生態系統中，yui是專業性及可擴展性的一例。我同他們進行了對比，因為我不斷受到他們代碼和文檔的影響。oocss不是一個真正意義上的框架，盡管我創建了很多例子，而是一種書寫可擴展，健壯，可維護性強的css的一種方式。也許最好的比喻是一個新的語言。最終，它是未知的javascript庫（it is javascript library agnostic），我希望貢獻代碼回yui及其他框架。
css框架太超過！我需要從頭開始編寫所有代碼嗎?
每需要一個隨機數字都要寫一個數字class嗎？
css is hard, not because it is broken , but because it is a legitimate technology requiring expertise to architect correctly. 為每個站點重復發明輪子非常的愚蠢。
源文件中右列在主列之前，會影響可訪問性，seo嗎？
我早期工作過的站點有更標準的模板結構，body上有一個極好的class，依靠這個模板顯示或隱藏左右列。自定義cms的用戶要創建一個3列布局的頁面時非常沮喪，發現需要兩列，找到它們不得不一個個從頭開始，因為有多個模板/起始點。你或許注意到主列是個流體列，在左右兩列渲染后自適應剩余的空間。
我更喜歡標簽排序勝過視覺排序（因為如果標簽順序改變會變得非常怪異），但是我也只想要一個模板。在web開發中經常遇到的是，兩個重要的目標發生了沖突，我做判斷如何解決。這種情況下標簽排序滿足視覺順序除了右列。在當前的代碼中，只需在html增加一個左或右列，沒有別處昂貴的dom變化。
屏幕閱讀器用戶有兩個選擇：
我的意見是對于跳過菜單這兩種方式足夠了。
每個人似乎都有一個回復觀點：seo，它們都不同，甚至相反。:)基于這個思潮，我傾向于：尤其對含有一定合理數量鏈接的導航菜單，不用太過在意。曾幾何時，我看到過導航鏈接被索引在搜索結果的內容部分，不過是在幾年前了。搜索爬蟲非常智能，我已經準備好想當然的認為如果我以語義化，干凈的方式標記內容，并非填充一坨垃圾鏈接，爬蟲能區分的出來。
把導航菜單標記為列表，允許屏幕閱讀器用戶跳過，并提供“跳至內容”鏈接，對可訪問性提供了雙倍的備用措施。
|||
為什么用了_ hack？我能把這些代碼放在單獨的文件中嗎？或者添加ie專有的class？
很顯然，首先考慮的是盡可能少和長遠。
我認為我的選擇有助于減少hack的總體數量，提升性能，并只有忽略不計的風險。話說回來，如果覺得代碼中的_令你作嘔，你完全可以移至單獨的文件。
為了添加表象效果比如邊框而使用空 <b> 標簽容器對象，會給屏幕閱讀器用戶帶來問題嗎？
不會，幸運的是屏幕閱讀器會忽略空的b標簽。使用這個表象標簽（b是加粗）來實現表象具有優勢。這個標簽可以通過服務器端腳本包含，以至于有一天所有的css圓角和陰影都支持了，可以關閉腳本并擁有漂亮，干凈，語義化的html。
oocss聲稱避免位置依賴的樣式。是否意味著我不能使用類似 .mymodule .title 的派生選擇器？
不使用派生選擇器沒什么阻礙，只是把它們放在更高的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/，有一些例子及下載等。
新聞熱點
疑難解答
