網(wǎng)站規(guī)劃之合理架構(gòu)css |
發(fā)布時間:2020-05-01 文章來源:本站 瀏覽次數(shù):2750 |
在當時瀏覽器普遍支撐的前提下,CSS被咱們賦予了史無前例的使命。但是依靠css越多,款式表文件就會變得越大越雜亂。與此同時,文件保護和安排的檢測也隨之而來。 (曾幾何時)只要一個css文件就夠了——一切規(guī)矩(rule)匯聚一堂,增修改都很便利——可這種日子早已遠去。(現(xiàn)在)樹立新網(wǎng)站時,有必要花點時刻好好籌劃怎樣安排和架構(gòu)css。 文件的安排 構(gòu)建css系統(tǒng)的第一步是綱要的擬定。(我以為)css安排規(guī)劃的重要性堪比網(wǎng)站目錄結(jié)構(gòu)。(HTMLor注:用詞夸大一點,讓你加深回憶) 沒有哪種計劃放之四海而皆準,因此咱們會討論一些根本的安排計劃,以及它們各自的利弊。 主css文件 通常能夠運用一個主css文件,來放置一切頁面同享的規(guī)矩。這個文件會包括默許的字體、鏈接、頁眉和其他等款式。有了主css文件之后,咱們開端討論高檔安排戰(zhàn)略。 辦法一:依據(jù)原型 最根本的戰(zhàn)略是依據(jù)原型頁面(archetype page)別離css文件。假定一個網(wǎng)站的主頁、子頁面和組合頁規(guī)劃不同,就能夠采用依據(jù)原型的戰(zhàn)略。(這種戰(zhàn)略下)每個頁面都會有專屬的css文件。 在原型數(shù)量不多的情況下,這個辦法簡略明了、行之有效。但是,當頁面元素并不墨守成規(guī)的位于各個原型頁時,問題就出現(xiàn)了。假定子頁面和組合頁同享某些元素,而主頁卻沒有,咱們應該怎樣做呢? 把同享元素放入主css文件。這雖不是最純粹的解決辦法,卻適用于某些具體情況。但是假定網(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ī)矩的重疊不一而足,并沒有一個徹底清晰無誤的計劃來安排它們。 辦法二:依據(jù)頁面元素/塊 假定網(wǎng)站運用服務器端include,這個辦法會很不錯。舉例說明,假定運用頁眉include,它會有自己相應的css文件。頁腳或許其他部分的include能夠如法炮制,只須導入自己的css文件。這個辦法簡略潔凈,不過可能會發(fā)作很多小css文件。 舉例來說,假定頁腳的款式只需求20行css代碼,單獨創(chuàng)立一個文件就劃不來了。并且這個辦法會導致每個頁面都包括一堆css文件——由于有多少include,就得有多少css文件。 辦法三:依據(jù)符號 這個計劃直觀實際,與前一個類似。假定網(wǎng)站共有30個頁面,其中10個含有form,那么能夠創(chuàng)立一個css文件專門處理form的款式,只在這10個頁面導入它。假定另外10個頁面含有table,就創(chuàng)立一個文件專門處理table款式……諸如此類。 另外的安排技巧 除了用片面的辦法安排文件,咱們還要考慮如打印、手持設備和屏幕等多種媒體類型。這盡管現(xiàn)已很清楚的界說過,可依舊是樹立文件結(jié)構(gòu)時應該考慮的一個因素。一旦有必要支撐多種媒體類型,主css文件里的某些規(guī)矩可能就得重新考慮。 另外,品牌聯(lián)合也可能是一個重要因素。(htmlor注:如google和nike聯(lián)手推出的joga) 假定觸及品牌聯(lián)合,你就得考慮哪些元素應該調(diào)整以適應另一品牌。比方別離運用不同的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)。你要決議是對選擇器編組(意味著隸屬),仍是把它們別離(意味著冗余)。編組能夠堅持代碼簡潔簡明,但是會樹立隸屬聯(lián)系,導致保護開銷添加。假定不編組,就會添加文件巨細,讓類似的選擇器堅持一致變得困難。只要做好這種權(quán)衡、取舍,才干每次都作出正確的決議。 按相互聯(lián)系/上下文編組 已然文件安排能夠是片面的,那么顯然,按照規(guī)矩和選擇器與其他部分的相互聯(lián)系來進行編組是最好的辦法。舉例說明,假定你用容器、頁眉和頁腳來完成布局,就應該把它們編成一組。 這似乎很簡略,其實不然。比方,把頁眉中的導航參加CSS時,是將它跟父元素編組仍是獨立編組?這種情況下,要視乎規(guī)矩的上下文。通常,頁眉與頁面布局相關,應該與其他布局元素一同編組。而導航是頁眉的一塊,應該和頁眉的其他塊編組,而不是頁眉自身。 運用注釋 跟大多數(shù)代碼類似,注釋是安排良好與否的要害。應該依據(jù)css的控制范圍,清楚的標示每節(jié)(section)。最好確保注釋視覺杰出,以便在內(nèi)容翻滾、一目十行時快速定位。 Doug Bowman在其文章《css安排技巧之一:符號》(CSS Organization Tip #1: Flags)里把css注釋玩得高超之極。他詳細說明了在節(jié)名之前加上等號,以便運用文本編輯器的查找功能敏捷跳到某節(jié)。 別忘了 你應該細致仔細的了解了特異性、級聯(lián)和承繼,并善用它們。它們之中的每一項都能夠是你最可怕的敵人,也能夠是你最友善的朋友。當樹立巨大的網(wǎng)站時,是否理解這些細微精妙之處,決議了你所構(gòu)建的是安如磐石的系統(tǒng),仍是經(jīng)不起風雨的豆腐渣工程。(HTMLor注:這句徹底意譯,比較爽) 特點的安排 現(xiàn)在咱們了解了文件的安排,也知道了文件內(nèi)規(guī)矩的安排,但還有一個重要的安排環(huán)節(jié)(沒有提到),那便是特點(attribute)。盡管特點比前兩個概念更簡略,但是還有一些非常好的、能夠堅持規(guī)矩整齊的辦法很值得一提。 按字母排序 提到特點,假定說需求遵循什么原則的話,那便是:按-字-母-排-序。其實這招關于特點瀏覽協(xié)助不大,不過能夠防止特點值掩蓋這種偶然事情的發(fā)作。 舉個例子吧,現(xiàn)已數(shù)不清有多少次,我為某個選擇器界說過了margin值,之后的某天無意間又加了一個(或前或后)。(這種情況下)后一個特點自然會起作用。假定不知道第二個特點存在,不論我怎樣調(diào)整第一個特點值、改寫瀏覽器,也看不到頁面變化。(htmlor注:這個問題我深有體會) 假定按照字母順序排列,你就會發(fā)現(xiàn)margin被界說了兩次(由于它們挨在一同),這個問題自然能夠避免。 優(yōu)先項 當網(wǎng)站雜亂、牽涉太多css文件時,會樹立很多的隸屬聯(lián)系。一旦需求定制某個元素特有的款式,!important選項似乎是最佳選擇。沒錯,!important是能解一時之需,但最好搞清楚導致問題的本源,然后依據(jù)級聯(lián)聯(lián)系決議是否真的需求用它。 假定你對上文提到的特異性、級聯(lián)和承繼很熟悉,大可不必抱著!important一顆樹不放。(htmlor注:整片森林等著你~) 當然它仍是會派上用場,不過運用之前要對具體情況了然于胸。千萬不要由于不知問題的癥結(jié)所在而把!important當作捷徑或是彌補計劃。 小結(jié) 當咱們變得依靠css而使款式表日漸雜亂時,就需求正確的計劃來避免犯錯,并使代碼易于保護。已然完美無缺的計劃并不存在,那么了解css的工作方式以及文件、選擇器和特點的多種安排計劃,無疑有助于咱們寫出優(yōu)質(zhì)的代碼,飽嘗住時刻檢測。 |
|