DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> CSS入門知識 >> DIV十CSS布局 >> 布局實例 >> 淺談合理架構CSS
淺談合理架構CSS
編輯:布局實例     

   架構CSS

  在當前浏覽器普遍支持的前提下,css被我們賦予了前所未有的使命。然而依賴css越多,樣式表文件就會變得越大越復雜。與此同時,文件維護和組織的考驗也隨之而來。

  (曾幾何時)只要一個css文件就夠了——所有規則(rule)匯聚一堂,增刪改都很方便——可這種日子早已遠去。(現在)建立新網站時,必須花點時間好好籌劃怎麼組織和架構css。

  文件的組織

  構建css系統的第一步是大綱的擬定。(我認為)css組織規劃的重要性堪比網站目錄結構。(注:用詞誇張一點,讓你加深記憶) 沒有哪種方案放之四海而皆准,因此我們會討論一些基本的組織方案,以及它們各自的利弊。

  主CSS文件

  通常可以使用一個主css文件,來放置所有頁面共享的規則。這個文件會包含默認的字體、鏈接、頁眉和其他等樣式。有了主css文件之後,我們開始探討高級組織策略。

  方法一:基於原型

  最基本的策略是基於原型頁面(archetype page)分離css文件。假如一個網站的首頁、子頁面和組合頁設計不同,就可以采用基於原型的策略。(這種策略下)每個頁面都會有專屬的css文件。

  在原型數量不多的情況下,這個方法簡單明了、行之有效。然而,當頁面元素並不按部就班的位於各個原型頁時,問題就出現了。如果子頁面和組合頁共享某些元素,而首頁卻沒有,我們應該怎麼做呢?

  把共享元素放入主css文件。這雖不是最純正的解決辦法,卻適用於某些具體情況。可是如果網站龐大,(這樣做的話)主css文件會迅速膨脹——這就違背了分離文件的初衷:避免導入不必要的大文件。

  在組合頁和子頁面的css文件裡各放一份樣式代碼。(這麼做)就意味著要維護冗余代碼,很顯然我們不想這樣。

  創建一個新的文件,由這兩種頁面共享。這聽起來不錯。不過假如只有10行代碼,我們創建這個文件僅僅是為了共享這10行代碼?(注:殺雞用牛刀?) 這方法很純粹,但如果網站龐大有很多對頁面共享很少量元素時(注:比如30對頁面分別共享10行代碼),就顯得很笨重了。

  創建一個單獨的css文件,包含所有共享元素的樣式。這方法可能比較簡單,卻要取決於網站的大小和共享元素的多少。有種情況會很煩:導入了一個很大的css文件,但頁面只用到一小部分樣式——還是那句話,這違背了分離文件的初衷。

  這就是我所說的重疊的兩難(overlap dilemma)。零碎css規則的重疊不一而足,並沒有一個完全清晰無誤的方案來組織它們。

  方法二:基於頁面元素/塊

  如果網站使用服務器端include,這個方法會很不錯。舉例說明,如果使用頁眉include,它會有自己相應的css文件。頁腳或者其他部分的include可以如法炮制,只須導入自己的css文件。這個方法簡單干淨,不過可能會產生很多小css文件。

  舉例來說,假如頁腳的樣式只需要20行css代碼,單獨創建一個文件就劃不來了。而且這個方法會導致每個頁面都包含一堆css文件——因為有多少include,就得有多少css文件。

  方法三:基於標記

  這個方案直觀實際,與前一個類似。如果網站共有30個頁面,其中10個含有form,那麼可以創建一個css文件專門處理form的樣式,只在這10個頁面導入它。如果另外10個頁面含有table,就創建一個文件專門處理table樣式……諸如此類。

  總結:

  CSS不僅僅是視覺設計,也不要因為你編寫CSS就隨便拋出編程的最佳實踐。像OOP、DRY、打開/閉合、與內容分離等這些規則應該應用到CSS裡面。無論你如何組織代碼,都要確保方法真正幫助到你,並且使你的開發更加容易和可維護的。

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