DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> CSS入門知識 >> CSS進階教程 >> OOcss教程:認識OOCSS和簡單應用OOCSS
OOcss教程:認識OOCSS和簡單應用OOCSS
編輯:CSS進階教程     

網頁制作poluoluo文章簡介:OOcss教程:認識OOCSS和簡單應用OOCSS.

  • 原文:http://wiki.github.com/stubbornella/oocss/faq(翻譯時為Version
    28)
  • 翻譯:ytzong

在OOCSS中怎麼定義“對象”?

對象類似JAVA中的類,保持著OO的特征。

一個CSS對象由4部分組成:

  1. 可能是一個或多個DOM節點的HTML
  2. 由wrapper節點的class名開始的CSS樣式聲明
  3. 類似於背景圖片和顯示用的sprites組件以及
  4. JavaScript行為,監聽或者與對象關聯的方法

這可能令人費解,因為每個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具有雙倍的性能優勢:

  1. 高度重用的CSS代碼,只需要很少的CSS代碼,意味著:
    • 更小的文件,從而更快的傳輸
    • CSS代碼在站點頁面中調用的比重增大則有希望被復用或被浏覽器緩存
  2. 就浏覽器而言更少的重繪和布局計算
    • 單個頁面,CSS規則復用的越多,渲染引擎花在“computed values”的計算時間越少
    • 手動增加的"extending"類,重寫更少的規則,這再一次意味著引擎做很少去應用規則

要用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的原因有兩個:

  1. 這使他們能快速創建復雜高點擊量的站點。他們不需糾結於不理解的結構除非有足夠的能力並充足的了解語法
  2. 學CSS時,他們不需創建丑陋的 “hello world!” 站點。設計師在非常在意的是他們的工作看起來很漂亮。如果必需做一些丑陋的東東,即便是學習之由,他們很快就會有挫敗感並灰常的郁悶。OO-CSS
    使得他們的工作在每個學習階段都看起來很漂亮

設計師是聰明D。我們要給他們信任。他們會講一種不同的,非工程師的語言,但是極客的語言經常以一種丑陋的方式來拒絕人。我們能做的更好。

我是個前端架構師,如何向團隊傳授OOCSS?

作為架構師,你應該寫結構對象;圓角如何創建,為角或其他特性放置表象元素,並處理浏覽器差異。新手為這些模塊寫皮膚(borders, colors, background
images, 等等)。

我用OO-CSS方式創建了大批站點(千級的頁面,百萬級的訪問者)。正確的完成後,很好擴展,這意味著新手將處理的個別元件可預見性很強。代碼審閱很容易,因為有可接受的方法明確的規則來擴展對象。這種回饋使新開發者快速生產。

我在FullSIX(一個法國的網絡營銷機構)管理一個前端開發團隊,是我工作過的最有才能的。某些時候我們的成功意味著我們將會有更多難以把控的工作。雇傭前端專家非常困難(沒有這種學校!),所以我開始對一些對寫代碼有興趣的設計師(很少或沒有經驗)推行一個內部實習項目,一個月就可以作為團隊的初級成員工作。

  • 第一周:學習語義並根據現有的CSS創建HTML。學習創建網頁:不需要更多的CSS,HTML語法,多個class,驗證,語義,介紹代碼審閱等
  • 第二周:創建簡單的內容對象(標題,列表等),持續一周。學習CSS語法,怎麼擴展對象,顏色,字體百分比,等等
  • 第三周:創建區塊的皮膚。邊框,顏色,背景圖片,基本的布局,sprites。讓他們同一個回答過n個問題的資深開發者一起工作,使他們少走彎路,他也應是很好的代碼審閱者。
  • 第四周:他們已經是團隊的皮膚制作成員了。

他們的代碼在一個客戶的網站上,同資深開發者寫的一樣好,或許更好因為他們還未學到一些壞習慣:)

入門:如何使用這些文件?

3個文件,libraries.css (reset 及 fonts 取自 yui), grids.css 及 template.css 已完成,其它的還非常不穩定。

  1. 打開template.html並存為新文件
  2. 通過擴展相應的對象來改寫列的數量及寬度。站點中只需一個模板,即使你有不同列的頁面,因為列也是對象。可以把它們當作任意的區域,可能會有0 ~ n
    個左列。查閱模板文檔可了解更多
  3. 用柵格來分割內容區域為小的區塊。查閱柵格文檔了解更多
  4. 添加內容。提示:這也應OO

如何部署在站點上?

注意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名優一些原則(排名不分先後):

  • 短 – 每一字節計算起來,所以盡可能保持class短
  • 清晰 – 可預料的行為/樣式要顯而易見
  • 語義化 – 對象什麼高過看起來像什麼。如何用在站點中?
  • 通用 – 名稱應該適用於多數站點。過於特殊的名稱減少了適用場合或導致語義化的class以非語義化的方式使用
  • 屏幕 – 移動閱讀器或打印樣式或許有不同的視圖,會重寫默認的屏幕視圖,所以當有沖突時class為屏幕而特殊定義(Different views
    might be provided by mobile or print stylesheets, however they override the
    default screen view, so the classes chosen are screen specific when there was
    a conflict)。這簡化了開發。

其它的框架如何?這只能同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變化。

屏幕閱讀器用戶有兩個選擇:

  1. 跳過鏈接
  2. 導航鏈接經常為一個鏈接列表或嵌套的鏈接列表形式。這非常有趣,因為這允許屏幕閱讀者通過屏幕閱讀器的特殊操作設置跳過整個列表。

我的意見是對於跳過菜單這兩種方式足夠了。

每個人似乎都有一個回復觀點:SEO,它們都不同,甚至相反。:)基於這個思潮,我傾向於:尤其對含有一定合理數量鏈接的導航菜單,不用太過在意。曾幾何時,我看到過導航鏈接被索引在搜索結果的內容部分,不過是在幾年前了。搜索爬蟲非常智能,我已經准備好想當然的認為如果我以語義化,干淨的方式標記內容,並非填充一坨垃圾鏈接,爬蟲能區分的出來。

把導航菜單標記為列表,允許屏幕閱讀器用戶跳過,並提供“跳至內容”鏈接,對可訪問性提供了雙倍的備用措施。

為什麼用了_ hack?我能把這些代碼放在單獨的文件中嗎?或者添加IE專有的class?

很顯然,首先考慮的是盡可能少和長遠。

  1. 添加一個單獨的樣式表獎增加一個額外的HTTP請求,增加整體文件的大小,這早已是浏覽器性能的對立點
  2. 我喜歡把一個對象的代碼放在一個地方。我認為這有助於減少hack的數量,尤其是當項目隨時間而發展
  3. IE6-的開發工具非常原始,這使得hack和普通代碼放在一起更加重要。我想能盡快找到一個可以使用屬性的IE bug。同樣,我認為這有助於減少hack
  4. 規則表明浏覽器理解不了的屬性會被忽略。對IE6-使用_早已眾所周知,可以合理的預料好的浏覽器將會忽略這個屬性
  5. 使用條件注釋意味著每個HTML頁面必須包含一個IE專用樣式。某一天(我不能等了!)當IE6的市場份額下降至像IE5那樣低時,我將去除這些代碼,但最後我要做的是觸及百級或千級的HTML頁面。我寧願只有依賴CSS
    hack的CSS,而不是把它放在HTML中。不幸的是,恕我直言,IE6兼容性的末日比我們期望的要更加長遠,因為IE中的quirksmode會回落到IE5.5的模式

我認為我的選擇有助於減少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/,有一些例子及下載等。

XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved