網站設計之合理架構css

來源:互聯網
上載者:User
架構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)。你要決定是對選取器編組(意味著附屬),還是把它們分離(意味著冗餘)。編組可以保持代碼簡潔扼要,可是會建立附屬關係,導致維護開銷增加。如果不編組,就會增加檔案大小,讓相似的選取器保持一致變得困難。只有做好這種權衡、取捨,才能每次都作出正確的決定。

  • 相關文章

    A Free Trial That Lets You Build Big!

    Start building with 50+ products and up to 12 months usage for Elastic Compute Service

    • Sales Support

      1 on 1 presale consultation

    • After-Sales Support

      24/7 Technical Support 6 Free Tickets per Quarter Faster Response

    • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.