網頁制作poluoluo文章簡介:OOcss教程:認識OOCSS和簡單應用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具有雙倍的性能優勢:
當你在同一頁面(或者同一站點同時緩存良好)復用一個對象時,這是性能的“免費贈品”。用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/,有一些例子及下載等。