萬盛學電腦網

 萬盛學電腦網 >> 網頁制作 >> DivCSS教程 >> div+css網頁布局時如何合理架構css?

div+css網頁布局時如何合理架構css?

   當前浏覽器普遍支持的前提下,css被我們賦予了前所未有的使命。然而依賴css越多,樣式表文件就會變得越大越復雜。與此同時,文件維護和組織的考驗也隨之而來。 (曾幾何時)只要一個css文件就夠了——所有規則(rule)匯聚一堂,增刪改都很方便——可這種日子早已遠去。(現在)建立新網站時,必須花點時間好好籌劃怎麼組織和架構css。

  文件的組織

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

  主css文件

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

  方法一:基於原型

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

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

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

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

  創建一個新的文件,由這兩種頁面共享。這聽起來不錯。不過假如只有10行代碼,我們創建這個文件僅僅是為了共享這10行代碼?(htmlor注:殺雞用牛刀?) 這方法很純粹,但如果網站龐大有很多對頁面共享很少量元素時(htmlor注:比如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文件裡的某些規則可能就得重新考慮。

  另外,品牌聯合也可能是一個重要因素。(htmlor注:如google和nike聯手推出的joga) 如果涉及品牌聯合,你就得考慮哪些元素應該調整以適應另一品牌。比如分別使用不同的css文件等。

  還有一個常被忽略的技巧:使用嵌套的@import語句。只包含一連串@import語句,或者再加幾句css規則,就能創建一個css文件。用這個方法完全可以創建網站的主css文件(用@import導入各部分的樣式文件)。假如網站的每個頁面都導入了4到5個不同的css文件,無疑你應該考慮使用這個技巧。

  規則和選擇器的組織

  談完了文件組織,接著討論一下怎麼組織文件裡的東西吧。很自然,我們希望在文件裡暢通無阻的浏覽,迅速找到要編輯的選擇器(selector)或規則。

  冗余 vs 附屬

  正如Dave Shea在其文章《冗余 vs. 附屬》(Redundancy vs. Dependency)裡所說的,你必須不斷了解級聯(cascade)。你要決定是對選擇器編組(意味著附屬),還是把它們分離(意味著冗余)。編組可以保持代碼簡潔扼要,可是會建立附屬關系,導致維護開銷增加。如果不編組,就會增加文件大小,讓相似的選擇器保持一致變得困難。只有做好這種權衡、取捨,才能每次都作出正確的決定。

  按相互關系/上下文編組

  既然文件組織可以是主觀的,那麼顯然,按照規則和選擇器與其他部分的相互關系來進行編組是最好的方法。舉例說明,假設你用容器、頁眉和頁腳來完成布局,就應該把它們編成一組。

  這似乎很簡單,其實不然。比如,把頁眉中的導航加入css時,是將它跟父元素編組還是獨立編組?這種情況下,要視乎規則的上下文。通常,頁眉與頁面布局相關,應該與其他布局元素一起編組。而導航是頁眉的一塊,應該和頁眉的其他塊編組,而不是頁眉本身。

  使用注釋

  跟大多數代碼類似,注釋是組織良好與否的關鍵。應該根據css的控制范圍,清楚的標注每節(section)。最好確保注釋視覺突出,以便在內容滾動、一目十行時快速定位。

  Doug Bowman在其文章《css組織技巧之一:標記》(CSS organization Tip #1: Flags)裡把css注釋玩得高明之極。他詳細說明了在節名之前加上等號,以便使用文本編輯器的查找功能迅速跳到某節。

  別忘了

  你應該細致認真的了解了特異性、級聯和繼承,並善用它們。它們之中的每一項都可以是你最可怕的敵人,也可以是你最友善的朋友。當建立龐大的網站時,是否理解這些細微精妙之處,決定了你所構建的是堅如磐石的系統,還是經不起風雨的豆腐渣工程。(htmlor注:這句完全意譯,比較爽)

  屬性的組織

  現在我們了解了文件的組織,也知道了文件內規則的組織,但還有一個重要的組織環節(沒有提到),那就是屬性(attribute)。雖然屬性比前兩個概念更簡單,可是還有一些非常好的、能夠保持規則整潔的方法很值得一提。

  按字母排序

  提到屬性,如果說需要遵循什麼原則的話,那就是:按-字-母-排-序。其實這招對於屬性浏覽幫助不大,不過可以防止屬性值覆蓋這種偶然事件的發生。

  舉個例子吧,已經數不清有多少次,我為某個選擇器定義過了margin值,之後的某天無意間又加了一個(或前或後)。(這種情況下)後一個屬性自然會起作用。假設不知道第二個屬性存在,不管我怎麼調整第一個屬性值、刷新浏覽器,也看不到頁面變化。(htmlor注:這個問題我深有體會) 如果按照字母順序排列,你就會發現margin被定義了兩次(因為它們挨在一起),這個問題自然可以避免。

  優先項

  當網站復雜、牽涉太多css文件時,會建立大量的附屬關系。一旦需要定制某個元素特有的樣式,!important選項似乎是最佳選擇。沒錯,!important是能解一時之需,但最好搞清楚導致問題的根源,然後根據級聯關系決定是否真的需要用它。

  如果你對上文提到的特異性、級聯和繼承很熟悉,大可不必抱著!important一顆樹不放。(htmlor注:整片森林等著你~) 當然它還是會派上用場,不過使用之前要對具體情況了然於胸。千萬不要因為不知問題的症結所在而把!important當作捷徑或是補救方案。

  小結

  當我們變得依賴css而使樣式表日漸復雜時,就需要正確的計劃來避免犯錯,並使代碼易於維護。既然完美無缺的方案並不存在,那麼了解css的工作方式以及文件、選擇器和屬性的多種組織方案,無疑有助於我們寫出優質的代碼,經受住時間考驗。

copyright © 萬盛學電腦網 all rights reserved