發(fā)布日期：2017/6/18

百度權(quán)重查詢 站長(zhǎng)交易 友情鏈接交換 網(wǎng)站監(jiān)控 服務(wù)器監(jiān)控 seo監(jiān)控

Philip Walton 在AppFolio擔(dān)任前端工程師，他在Santa Barbara on Rails的聚會(huì)上提出了CSS架構(gòu)和一些好佳實(shí)踐，并且在工作中一向沿用。

擅長(zhǎng)CSS的Web開發(fā)人員不僅可以從視覺上復(fù)制實(shí)物原型，還可以用代碼進(jìn)行好的呈現(xiàn)。無需使用表格、盡可能少的使用圖片。假如你是個(gè)名副其實(shí)的高手，你可以快速把好新和好偉大的技術(shù)應(yīng)用到你的項(xiàng)目中，比如媒體查詢、過渡、濾鏡、轉(zhuǎn)換等。雖然這些都是一個(gè)真正的CSS高手所具備的，但CSS很少被人單獨(dú)拿出來討論，或者用它去評(píng)估某個(gè)人的技能。

有趣的是，我們很少這樣去評(píng)價(jià)其他語(yǔ)言。Rails開發(fā)人員并不會(huì)因?yàn)槠浯�碼比較規(guī)范，就認(rèn)為他是一名優(yōu)異的開發(fā)人員。這僅僅是個(gè)基準(zhǔn)。當(dāng)然，他的代碼得必須規(guī)范。另外，還需薈萃其他方面考慮，比如代碼是否可讀？是否容易修改或擴(kuò)展……

這都是些很天然的問題，CSS和它們并沒有什么不同之處。今天的Web應(yīng)用程序要比以往更加重大。一個(gè)缺乏深思熟慮的CSS架構(gòu)往往會(huì)削弱發(fā)展，是時(shí)候像評(píng)估其他語(yǔ)言那樣，來評(píng)估一下CSS架構(gòu)了，這些都不應(yīng)該放在“事后”考慮或者單單屬于設(shè)計(jì)師們的事情。

1.的CSS架構(gòu)目標(biāo)

在CSS社區(qū)，很難提出某個(gè)好佳實(shí)踐已經(jīng)成為大家的普遍共識(shí)。純粹地從Hacker News的評(píng)論上判斷和開發(fā)者們對(duì)CSS Lint發(fā)布后的反應(yīng)來看，大多數(shù)人對(duì)基本的CSS東西是持反對(duì)意見的。所以，并不是為自己的好佳實(shí)踐奠定一套基本的論據(jù)，而應(yīng)該確定真正的目標(biāo)。

好的CSS架構(gòu)目標(biāo)并不同于開發(fā)一個(gè)好的應(yīng)用程序，它必須是可展望、可重用、可維護(hù)和可伸縮的。

可展望

可展望意味著可以像預(yù)期的那樣規(guī)范自己的行為。當(dāng)你添加或者修改某個(gè)規(guī)則時(shí)，它并不會(huì)影響到?jīng)]有指定的部分。對(duì)于一個(gè)小網(wǎng)站來說，一些微乎其微的改變并不算什么。而對(duì)于擁有成千上萬(wàn)個(gè)頁(yè)面的大網(wǎng)站來說，可展望卻是必須的。

可重用

CSS規(guī)則應(yīng)具備抽象息爭(zhēng)耦性，這樣你就可以在現(xiàn)有的基礎(chǔ)上快速構(gòu)建新的組件，無需重新修改編碼模式。

可維護(hù)

當(dāng)把新組件放置到網(wǎng)站上，并且執(zhí)行添加、修改或者重新設(shè)計(jì)操作時(shí)，無需重構(gòu)現(xiàn)有CSS，并且新添加的X并不會(huì)打破原有頁(yè)面的Y組件。

可擴(kuò)展

當(dāng)網(wǎng)站發(fā)展到一定規(guī)模后，都需要進(jìn)行維護(hù)和擴(kuò)展。可擴(kuò)展的CSS意味著網(wǎng)站的CSS架構(gòu)可以由個(gè)人或者團(tuán)隊(duì)輕易地管理，無需花費(fèi)太多的學(xué)習(xí)成本。

2.常見的錯(cuò)誤實(shí)踐

在實(shí)現(xiàn)的CSS架構(gòu)目標(biāo)之前，我們來看一些常見的錯(cuò)誤做法，這對(duì)我們達(dá)成目標(biāo)是有益處的。

下面的這些例子雖然都可以很好的執(zhí)行，但卻會(huì)給你帶來許多煩惱，盡管我們的意圖和愿望都是美好的，但是這些開發(fā)模式會(huì)讓你頭疼。

幾乎在每個(gè)網(wǎng)站上，都會(huì)有一個(gè)特定的虛擬元素看起來與其他頁(yè)面是完全一樣的，然而只有一個(gè)頁(yè)面除外。當(dāng)面對(duì)這樣一種情況時(shí)，幾乎每個(gè)新手CSS開發(fā)人員（甚至是經(jīng)驗(yàn)雄厚的）都會(huì)以同樣的體例來修改。你應(yīng)該為該頁(yè)面找出些與眾不同之處（或者自己創(chuàng)建），然后再寫一個(gè)新規(guī)則去操作。

基于父組件來修改組件

.widget {

background： yellow;

border： 1px solid black;

color： black;

width： 50%;

}

#sidebar .widget {

width： 200px;

}

body.homepage .widget {

background： white;

}

初看，這是段無害的代碼，但讓我們來看看它是否達(dá)到了我們所設(shè)置的目標(biāo)。

首先，widget在examle是不可預(yù)見的。當(dāng)這些小部件出現(xiàn)在頁(yè)面兩側(cè)或者主頁(yè)面時(shí)，開發(fā)人員期望它們以某種特定的體例顯示出來，且又不失特色。另外，它也是不可重用或不可擴(kuò)展的。

另外，它也比較難維護(hù)。一旦這個(gè)widget需要重新設(shè)計(jì)，那么你不得不修改其他幾個(gè)CSS樣式。想象一下，假如這段代碼是使用其他語(yǔ)言編寫的，它基本就是一個(gè)類定義，然后在代碼的另一部分使用該類定義并做出擴(kuò)展。這直接違反了軟件開發(fā)的開放/閉合（open/close）原則。

過于復(fù)雜的選擇器

偶爾，會(huì)有些文章介紹CSS選擇器對(duì)整個(gè)網(wǎng)站的展示起著特別很是主要的作用，并且宣稱無需使用任何類選擇器或者ID選擇器。

但伴隨著越深入的開發(fā)，我越會(huì)遠(yuǎn)離這種復(fù)雜的選擇器。一個(gè)選擇器越復(fù)雜，與HTML就越耦合。依靠HTML標(biāo)簽和組合器可以保持HTML代碼干干凈凈，但卻讓CSS更加毛重和凌亂。

#main-nav ul li ul li div { }

#content article h1:first-child { }

#sidebar > div > h3 + p { }

對(duì)上面代碼進(jìn)行簡(jiǎn)單的理解。個(gè)可能是對(duì)下拉菜單進(jìn)行樣式化；第二個(gè)想說明文章的主題目應(yīng)該與其他頁(yè)面的H1元素不同；好后一個(gè)透露表現(xiàn)在段的側(cè)邊欄區(qū)域添加一些額外的空間。

假如這個(gè)HTML是永遠(yuǎn)不變的，那就無可說之處，但這根本毫不現(xiàn)實(shí)。過于復(fù)雜的選擇器會(huì)讓人印象深刻，它可以讓HTML脫節(jié)掉外觀上的復(fù)雜，但對(duì)于實(shí)現(xiàn)的CSS架構(gòu)目標(biāo)卻毫無用處。

上面提到的例子都是不具備可展望性、可重用、可擴(kuò)展和可維護(hù)這四大特征的。例如個(gè)選擇器（下來菜單）例子，假如一個(gè)外觀特別很是相似的下拉列表需要用在不同的頁(yè)面上，并且#main-nav并不屬于內(nèi)部元素，那么你是否需要重新設(shè)計(jì)？假設(shè)開發(fā)者想要修改第三個(gè)例子里div里面部分標(biāo)記，那么整個(gè)規(guī)則都會(huì)被打破。

過于通用的類名

當(dāng)創(chuàng)建可重用的設(shè)計(jì)組件時(shí)，在組件的類選擇器中覆蓋附件的子元素是很常見的現(xiàn)象。例如：

<div class=“widget”>

<h3 class=“title”>。..</h3>

<div class=“contents”>

Lorem ipsum dolor sit amet， consectetur adipiscing elit.

In condimentum justo et est dapibus sit amet euismod ligula ornare.

Vivamus elementum accumsan dignissim.

<button class=“action”>Click Me！</button>

</div>

</div>

.widget {}

.widget .title {}

.widget .contents {}

.widget .action {}

像.title、.contents、.action這些子元素類選擇器可以被安全地進(jìn)行樣式命名，無需憂慮這些樣式會(huì)蔓延到擁有相同類名的其他元素中。這是千真萬(wàn)確的。但它并沒有阻止相同樣式類名稱會(huì)蔓延到這個(gè)組件上。

在一些大型項(xiàng)目上，像.title這樣的名稱很有可能會(huì)被用在另外一個(gè)頁(yè)面或者自己。假如這樣的情況發(fā)生，那么整個(gè)題目部分顯明會(huì)和預(yù)期的不一樣。

過于通用的類選擇器名稱會(huì)導(dǎo)致許多不可展望的CSS樣式發(fā)生。

一個(gè)規(guī)則做太多事

有時(shí)，你要在網(wǎng)站的左上角區(qū)域做一個(gè)20pixels的可視化組件。

.widget {

position： absolute;

top： 20px;

left： 20px;

background-color： red;

font-size： 1.5em;

text-transform： uppercase;

}

下面，你需要在網(wǎng)站的其他區(qū)域使用該組件，那么上面的這個(gè)代碼顯明是錯(cuò)誤的，不可重用的。

問題的關(guān)鍵是你讓.widget這個(gè)選擇器做的事情太多，不僅對(duì)該組件的位置進(jìn)行了規(guī)定，還對(duì)它的外觀和感覺方面進(jìn)行了樣式。外觀和感覺可以通用，而位置是不可以的。有時(shí)候，把它們整合起來使用反而會(huì)大打折扣。

雖然這些看起來并無害處，對(duì)一些缺乏經(jīng)驗(yàn)的CSS程序員來說，復(fù)制和粘貼已經(jīng)成為一種習(xí)慣。假如一個(gè)新團(tuán)隊(duì)需要一個(gè)特定組件，比如.infobox，他們會(huì)嘗試使用這個(gè)類選擇器。但假如該信息框沒有按照期望的那樣，在每個(gè)需要的地方準(zhǔn)確顯示出來。這時(shí)，你認(rèn)為他們會(huì)怎么做？以我的經(jīng)驗(yàn)來看，他們會(huì)打破可重用這一規(guī)則，相反，他們會(huì)簡(jiǎn)單地把這些代碼復(fù)制粘貼到每個(gè)需要的地方。做些不需要的重復(fù)工作。

3.原因

上面列舉的這些常規(guī)錯(cuò)誤實(shí)踐都有一個(gè)相似性，CSS樣式承擔(dān)過多。

對(duì)這樣的說法你會(huì)感到新鮮，畢竟，它是一個(gè)樣式表，難道不應(yīng)該承擔(dān)大多數(shù)（假如不是悉數(shù)）的樣式嗎？那不正是我們想要的嗎？

的確。但是通常來講，事情并沒有那么簡(jiǎn)單。內(nèi)容與體現(xiàn)（presentation）相星散是件好事，但CSS從HTML中自力出來并不意味著內(nèi)容也需要從體現(xiàn)中星散。換句話說，假如CSS請(qǐng)求深入分析HTML架構(gòu)，那么從HTML中分拆所有的顯示代碼并不一定會(huì)實(shí)現(xiàn)所有的目標(biāo)。

此外，HTML很少會(huì)只包含內(nèi)容，也透露表現(xiàn)整體框架。通常，架構(gòu)是會(huì)包含container元素，許可CSS隔離一些固定元素。即使沒有表象類（presentational classes），也能混合HTML清晰地把內(nèi)容展示出來。

我相信，鑒于當(dāng)前的HTML和CSS狀況，把HTML和CSS明智地結(jié)合起來，當(dāng)做體現(xiàn)層是特別很是需要的。而通過模板和局部模板（partials）也可以把內(nèi)容層進(jìn)行星散。

1 2 下一頁(yè)