| 網(wǎng)站設計之合理架構css 發(fā)布時間：2014-10-12 00:14:10 |
| 架構css 在當前瀏覽器普遍支持的前提下，css被我們賦予了前所未有的使命。然而依賴css越多，樣式表文件就會變得越大越復雜。與此同時，文件維護和組織的考驗也隨之而來。 (曾幾何時)只要一個css文件就夠了——所有規(guī)則(rule)匯聚一堂，增刪改都很方便——可這種日子早已遠去。(現(xiàn)在)建立新網(wǎng)站時，必須花點時間好好籌劃怎么組織和架構css。 文件的組織 構建css系統(tǒng)的第一步是大綱的擬定。(我認為)css組織規(guī)劃的重要性堪比網(wǎng)站目錄結構。(htmlor注:用詞夸張一點，讓你加深記憶) 沒有哪種方案放之四海而皆準，因此我們會討論一些基本的組織方案，以及它們各自的利弊。 主css文件 通常可以使用一個主css文件，來放置所有頁面共享的規(guī)則。這個文件會包含默認的字體、鏈接、頁眉和其他等樣式。有了主css文件之后，我們開始探討高級組織策略。 方法一:基于原型 最基本的策略是基于原型頁面(archetype page)分離css文件。假如一個網(wǎng)站的首頁、子頁面和組合頁設計不同，就可以采用基于原型的策略。(這種策略下)每個頁面都會有專屬的css文件。 在原型數(shù)量不多的情況下，這個方法簡單明了、行之有效。然而，當頁面元素并不按部就班的位于各個原型頁時，問題就出現(xiàn)了。如果子頁面和組合頁共享某些元素，而首頁卻沒有，我們應該怎么做呢? 把共享元素放入主css文件。這雖不是最純正的解決辦法，卻適用于某些具體情況�？墒侨绻W(wǎng)站龐大，(這樣做的話)主css文件會迅速膨脹——這就違背了分離文件的初衷:避免導入不必要的大文件。 在組合頁和子頁面的css文件里各放一份樣式代碼。(這么做)就意味著要維護冗余代碼，很顯然我們不想這樣。 創(chuàng)建一個新的文件，由這兩種頁面共享。這聽起來不錯。不過假如只有10行代碼，我們創(chuàng)建這個文件僅僅是為了共享這10行代碼?(htmlor注:殺雞用牛刀?) 這方法很純粹，但如果網(wǎng)站龐大有很多對頁面共享很少量元素時(htmlor注:比如30對頁面分別共享10行代碼)，就顯得很笨重了。 創(chuàng)建一個單獨的css文件，包含所有共享元素的樣式。這方法可能比較簡單，卻要取決于網(wǎng)站的大小和共享元素的多少。有種情況會很煩:導入了一個很大的css文件，但頁面只用到一小部分樣式——還是那句話，這違背了分離文件的初衷。 這就是我所說的重疊的兩難(overlap dilemma)。零碎css規(guī)則的重疊不一而足，并沒有一個完全清晰無誤的方案來組織它們。 方法二:基于頁面元素/塊 如果網(wǎng)站使用服務器端include，這個方法會很不錯。舉例說明，如果使用頁眉include，它會有自己相應的css文件。頁腳或者其他部分的include可以如法炮制，只須導入自己的css文件。這個方法簡單干凈，不過可能會產(chǎn)生很多小css文件。 舉例來說，假如頁腳的樣式只需要20行css代碼，單獨創(chuàng)建一個文件就劃不來了。而且這個方法會導致每個頁面都包含一堆css文件——因為有多少include，就得有多少css文件。 方法三:基于標記 這個方案直觀實際，與前一個類似。如果網(wǎng)站共有30個頁面，其中10個含有form，那么可以創(chuàng)建一個css文件專門處理form的樣式，只在這10個頁面導入它。如果另外10個頁面含有table，就創(chuàng)建一個文件專門處理table樣式……諸如此類。 另外的組織技巧 除了用主觀的方法組織文件，我們還要考慮如打印、手持設備和屏幕等多種媒體類型。這雖然已經(jīng)很清楚的定義過，可依舊是建立文件結構時應該考慮的一個因素。一旦必須支持多種媒體類型，主css文件里的某些規(guī)則可能就得重新考慮。 另外，品牌聯(lián)合也可能是一個重要因素。(htmlor注:如google和nike聯(lián)手推出的joga) 如果涉及品牌聯(lián)合，你就得考慮哪些元素應該調整以適應另一品牌。比如分別使用不同的css文件等。 還有一個常被忽略的技巧:使用嵌套的@import語句。只包含一連串@import語句，或者再加幾句css規(guī)則，就能創(chuàng)建一個css文件。用這個方法完全可以創(chuàng)建網(wǎng)站的主css文件(用@import導入各部分的樣式文件)。假如網(wǎng)站的每個頁面都導入了4到5個不同的css文件，無疑你應該考慮使用這個技巧。 規(guī)則和選擇器的組織 談完了文件組織，接著討論一下怎么組織文件里的東西吧。很自然，我們希望在文件里暢通無阻的瀏覽，迅速找到要編輯的選擇器(selector)或規(guī)則。 冗余 vs. 附屬 正如Dave Shea在其文章《冗余 vs. 附屬》(Redundancy vs. Dependency)里所說的，你必須不斷了解級聯(lián)(cascade)。你要決定是對選擇器編組(意味著附屬)，還是把它們分離(意味著冗余)。編組可以保持代碼簡潔扼要，可是會建立附屬關系，導致維護開銷增加。如果不編組，就會增加文件大小，讓相似的選擇器保持一致變得困難。只有做好這種權衡、取舍，才能每次都作出正確的決定。 相關說明： 您可以通過電話：020-85421558 與我們聯(lián)系，我們會根據(jù)您所從事的行業(yè)領域和網(wǎng)站類型，在最短的時間內請我們的營銷顧問與您預約后上門拜訪您，直接面談交流為您解答所有的網(wǎng)站建設疑問。 |
 |
- 網(wǎng)站建設套餐
- 普通版網(wǎng)站套餐
- 標準版網(wǎng)站套餐
- 全能版網(wǎng)站套餐
- 微站/手機網(wǎng)站建設套餐
- 營銷型網(wǎng)站建設套餐
- 更多網(wǎng)站建設套餐
- 網(wǎng)站定制開發(fā)
- 品牌網(wǎng)站建設
- 商城網(wǎng)站建設
- 外貿網(wǎng)站建設
- 門戶網(wǎng)站建設
- 微網(wǎng)站建設
- 移動APP
- 云虛擬主機
- 購買云虛擬主機
- 云虛擬主機優(yōu)勢
- M型云虛擬主機
- G型云虛擬主機
- 海外云虛擬主機
- 數(shù)據(jù)空間
- SQL數(shù)據(jù)空間
- 魔方主機
- 購買魔方主機
- 魔方主機概念和優(yōu)勢
- 魔方主機功能列表
- 企業(yè)郵箱
- 購買企業(yè)郵箱
- 企業(yè)郵箱優(yōu)勢
- 企業(yè)郵局后臺管理功能
- 企業(yè)400電話
- 400電話申請
- 關于400電話
- 400資費標準
- 400特點與優(yōu)勢
- 400常見問題
- 網(wǎng)站優(yōu)化（套餐）
- 網(wǎng)站優(yōu)化全包套餐（年付）
- 關鍵詞優(yōu)化套餐，可選（年/季/月）付
- 多引擎（關鍵詞按天扣費）
- （百度/360/搜狗/搜搜/有道）按天扣費
- 百度（關鍵詞按天扣費）
- 百度關鍵詞按天扣費