国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

如何寫好CSS?

Yuqi / 2825人閱讀

摘要:由此按照的指導原則,我們應該寫一個,然后為其添加一些之類的來差異化它這樣在以上兩種附加的作用下,我們在中就可以獲得種不同的樣式,隨著附加增加,的樣式也會呈指數增加,千變萬化。

真正的問題是什么?

CSS即層疊樣式表,所以一層一層覆蓋其實是其本質特征。真正的問題在于維護,許多人認為CSS僅是樣式,不是代碼,無需維護,所以任意書寫,只要將自己需要的樣式的優先級設為最高即可,才導致了深層級CSS的出現,因為每次添加一個樣式就必須比以前的優先級高才能在頁面看到。深層級不僅造成維護性降低,可讀性也是一個問題,人不是機器,無法很優雅的按優先級閱讀,所以很難確認一個樣式用于哪里,其實還存在許多的冗余樣式,在任何地方都被覆蓋的樣式。這樣的代碼在擴展性上,一開始反而是有優勢的,因為添加一個新class,無需擔心影響其他地方,但慢慢隨著項目規模的增大,頁面增多,需要復制樣式的地方也越來越多,它們之間又存在微小的差異,設計的更改,需求的變化,這一切都會將這種快餐式的CSS推進柏油坑。因為難以維護,所以無法響應需求,所以無法復用,只能復制,惡性循環。

正如上面所說的,問題在于可讀性、維護性、擴展性、復用性這幾個方面。所以只要提高它們就能解決問題, 雖然這么說,也不是如此簡單的。先來談談在CSS中,這些概念都有著怎樣的意義。

可讀性

有人認為CSS不是程序,不需要可讀性,有人認為CSS只要寫出來就有可讀性,因為很簡單。拋開各種預處理器不說,原生CSS結構確實簡單,沒有需要編程的部分,但仍然可能導致混亂。原因有二,一是CSS可以層疊,其中涉及到了優先級和作用范圍,如果寫的不好,人很難讀出其中的意義,二是CSS屬性眾多,加上CSS3引入了很多用法獨特的屬性,一個選擇器可能包含幾十個屬性。比如下面這段我隨便寫的CSS代碼:

span {
    -webkit-box-shadow: 6px 4px 4px red;
    -moz-box-shadow: 6px 4px 4px red;
    box-shadow: 6px 4px 4px red;
}
div span {
    border-width: 4px;
    border-style: dotted;
    border-color: blue;
}
#box {
    border-left: 2px solid red;
    border-bottom: 2px solid red; 
}

乍一看也沒什么,都是border,大致能看出來這段CSS只是為了添加一個紅色的陰影讓box看起來比較立體。但中間的部分似乎是搗亂的,你可能會說這太傻了,看不到嗎。是的,當這3部分散落在上萬行的CSS中時,肯定看不到。于是有人很自然的想起了我們可愛的瀏覽器,沒錯,在瀏覽器中可以快速找到作用于目標的CSS樣式,但這也是萬惡之源。首先我假設你不知道中間那部分東西是為了什么而寫的,因為你是靠瀏覽器找到它的。然后剩下兩種可能,不管三七二十一改了再說和看看它為什么存在。前者悲劇的可能性是100%,后者悲劇的可能性是90%,因為你已經掉坑里了,很快我們會發現要修改它還牽扯到了另外的地方,接著在瀏覽器中探索到另一個莫名其妙的樣式,當你弄懂全部的時候,你應該已經把上萬行的代碼弄了個一清二楚了,也許最幸運的是,浪費了幾個小時的時間發現只需要修改一行就能達到目的。

當然,我們可以天真的認為,只要把他們寫在一起就可以了,這樣找起來很簡單。而我將繼續順著這樣的思路來嘗試曝露問題。

維護性

所謂物以類聚是很有道理的,人們習慣將事物歸類,但問題是分類標準,樣式并不關心業務,無論是什么文字內容,還是功能有何不同,它在乎的只是樣式,比如文字的尺寸,間距和寬高,顏色等等。如果簡單的將一個組件的樣式放在一起,勢必帶來的就是小段代碼的重復書寫。不覺得有多嚴重?我來舉個栗子。

aside {
    box-shadow: 6px 4px 4px #AA3343;
}
nav {
    box-shadow: 6px 4px 4px #AB3633;    
}
.item {
    box-shadow: 6px 4px 4px #AA3732;
}
.item.otherStatus {
    box-shadow: 6px 4px 4px #AA3132;
}

繼續說上面的例子,box需要陰影,但如果這個項目的UI統一風格,包括sidebar,navigator以及item都需要這樣的陰影呢?再如果,明天客戶或者UX一拍腦袋,這個陰影應該是灰色的不該是紅色的呢?不要繼續天真的認為全局替換是救命稻草。首先,沒有幾個網站會用red,blur做色調的,你用的應該是#AA3333,這樣的代碼,然后你發現sidebar用了#A43433,而navigator是#AB3633,等等,item有兩個狀態,而兩個狀態對應的顏色是不一樣的。這怎么可能?但當你打開瀏覽器的時候你會發現本來就相差無幾的顏色,在陰影中變得一模一樣了,誰看的出來呢,當初使用的時候可能也不過是隨意的在mockup中取的一個顏色。

大量的重復帶來的不僅僅是代碼的冗余,我們必須靠人力去同步它們,而人很難保證它們的修改是完全一致的,尤其是當它們中引入了一些不一致的獨特的東西時。不要小看CSS,其后果就是進度和人力的壓力,后面就是PM有沒有讀過《人月神話》的事了。

肯定有人在想,誰讓你當初要寫成這樣呢。我們在讀代碼的時候最喜歡問,當初為什么要這么寫?但慢慢的你會讀出它的歷史,有時候它是身不由己的。這就涉及到了下一個要討論的內容。

擴展性

擴展性是一個具有欺騙性的東西,所謂的擴展性其實就是在現有基礎上再次開發新東西的性能,但我認為它還必須有前提條件,那就是保持可讀性與維護性。

簡單的追求可維護性是自取滅亡,原因很簡單,將新舊代碼完全分離的時候擴展性最高,因為不必擔心對以前的部分有影響,新的樣式可以隨意發揮。是不是很神奇,這樣想的我們寫下的代碼,肯定就是前面我們追問的代碼。所以自己回答自己吧,當初沒考慮可讀性和維護性,只想著快點增加新的樣式,就這么寫了。

那什么才是一個好的擴展性呢,簡單來說,就是多功能產品。比如一個box,也許它的樣式就時

復用性

似乎我一直在說的就是重復,那我們就來說說復用性,如何才能復用CSS代碼是一個很大的問題,比如粒度,是一兩個屬性進行復用還是一大組選擇器進行復用呢,再比如對象,是為了class復用屬性,還是為了html復用class呢。這些選擇不算太重要,但是帶來的影響卻很重大,可以說是整個CSS結構的改變。下面繼續用box的陰影來討論復用。

.shadow {
    -webkit-box-shadow: 6px 4px 4px #A93334;
    -moz-box-shadow: 6px 4px 4px #A93334;
    box-shadow: 6px 4px 4px #A93334;
    border-left: 2px solid #A933349;
    border-bottom: 2px solid #A933349; 
}

這樣看起來我有了一個shadow的class可以給任意的目標加上這個陰影了,但這導致了一個復用的問題,和上面那段搗亂的CSS樣式一樣,如果item已有另外2個border了,那這個class是無法去除的。所以復用時不僅要考慮需要什么,還要考慮不需要什么。另外一些必須的屬性比如display還有overflow等也是要考慮的,因為user agent的原因,很多屬性是隱藏在element中的。

如何解決問題?

主流的CSS原則有OOCSS,DRY,SMACSS以及BEM,他們皆是為解決CSS的各種問題而生。

OOCSS

OOCSS即面向對象的CSS,這里對象指的是頁面中的元素對象,與傳統編程中的面向對象不太相同,比如不存在方法這種東西,硬要說的話,附加的一些class可以看作是繼承或者接口之類的東西來實現對象的差異化。比如電商網站中的商品就是一個典型的對象,它們既有許多相同的部分,又有許多差異,寬高、按鈕、圖片、標題等基本布局都是相同的,而邊距、線框、背景顏色、字號等都是差異化的。由此按照OOCSS的指導原則,我們應該寫一個product class,然后為其添加一些border、theme之類的class來差異化它:

.product {
    display: block;
    overflow: hidden;
    float: left;
    width: 200px;
    height: auto;
}
.product-head{...}
.product-body{...}
.product-foot{...}

.product-theme-black {
    background: black;
    color: white;
}

.product-border {
    border: 1px solid #333;
}

這樣在以上兩種附加class的作用下,我們在html中就可以獲得4種不同的product樣式,隨著附加class增加,product的樣式也會呈指數增加,千變萬化。這僅僅是一個簡單的例子,意在點出OOCSS的理念,但并沒有突出它的意義所在。別著急,先來看看OOCSS的兩大原則。

1. 分離容器與內容

所謂的容器即包裹對象的元素,比如一個div,我們經常會命名為wrap、container、body等。那么如何才算是分離容器與內容呢?很簡單,一句話,內容在哪都可用。也就是說不應該出現這樣的情況:

.container .product {
    ...
}

這樣干的結果就是復用性大大降低,因為只能在這個容器內使用它了。但這并不代表我們應該將所需的樣式全部一股腦的扔進多帶帶的class中,對于差異化應該多帶帶放在一個class中,這才是OOCSS的精髓。

舉個例子,當我們既不想犧牲太多性能,又想來個瀑布流顯擺顯擺的時候,大部分前端都會使用column,類似泳道的設計。你想說哦不,這是偽pinterest,但是誰在乎呢,用戶是不會有閑工夫拖拽瀏覽器的寬度來鑒別它的,在IE下商品多的時候至少不會太卡。哈,別較真,首先分為幾個column,然后按照高度往里填放商品,先來看看下面的代碼吧,我有省略一些樣式避免誤導:

.column {
    height: auto;
    width: 200px;
}

.product {
    width: 180px;
    margin-right: 20px;
    margin-bottom: 10px;
}

看起來不錯,每列200px寬,商品放入其中,水平間距要大,垂直間距要小些才像column。但是等等,我們總還是需要整齊擺放的商品列表的對不對。也許margin并不是product的必要屬性,至少它應該是可變的。我們抽出它來:

.product {
    width: 180px;
}

.vertical-product {
    height: 400px;
    margin-right: 10px;
    margin-bottom: 10px;
}

.horizontal-product {
    height: auto;
    margin-right: 20px;
    margin-bottom: 10px;
}

這樣便將column或list之類的容器與product分開來毫無關系了,即使以后出現了其他組織形式,只要product的基本結構沒有變都可以直接復用,無非是添加一些附屬樣式到新的xxx-product的class中。另外這樣做還有一個好處,設計邏輯放在了HTML中,CSS更加強大。

什么是樣式邏輯?商品在瀑布流中不定高,在列表中定高,這就是一種樣式的邏輯,如果用父子選擇器的形式寫在CSS中,那它就失去了自由。而放在HTML通過選擇添加何種附屬class來展現不同形式的product,則非常的自由與靈活。另外值得一說的是,margin-bottom是一樣的,但我們應該各自放在各自的class里面,原因很簡單,它們僅僅是一不小心恰好一樣,在設計邏輯中它們并不是一樣的bottom,這里并不是重復,而是看起來一樣。如果以后需要改變其中的一個bottom,共用則顯得非常別扭。

2. 分離皮膚與結構

第二點很容易理解,皮膚(theme)就是視覺效果,即使被剔除網頁也沒有什么影響的就是皮膚;而結構指地并不是像HTML這樣抽象的結構,因為CSS畢竟還是樣式,所以結構只是相對的頁面結構。

先來看看我們的product吧,添加一些背景色和邊框:

.product {
    width: 200px;
    background: #F6F2F2;
    border: 1px solid #C4A0A0;
}

看起來還不錯,不過設計師都是自大狂,精心的調色,完美的搭配,絕對不會讓你僅僅使用這么一次的,頁面的其他模塊、sidebar甚至是header都可能采用相同的背景顏色與邊框,它們甚至可能互相嵌套。好吧,這其實在設計上是為了視覺統一,畢竟沒有幾個設計大師能hold住3,4種以上的顏色。所以我們能做的并不是在每個class中添加這樣的樣式,而是把它提出來成為獨立的class,原因就像我開篇說的那樣,顏色為混沌之源。

.main-bg {
    background: #F6F2F2;
}

.main-border {
    border: 1px solid #C4A0A0;
}

這樣就可以在頁面中隨時使用主要的設計元素了,而且需要修改時也非常的簡單,不用擔心有什么地方漏掉。另外我將背景與邊框分為了兩個class,原因還是設計邏輯應該放在HTML,背景與邊框并不是一定同時出現的,兩者的關系應該由HTML決定,即使設計上邏輯決定了兩者的綁定,在實現時也有可能因為HTML結構而放在兩個不同的元素上。

OOCSS強調class,將每組樣式寫成一個class方便HTML中使用,眾多class組合起來能千變萬化組成一個對象。所以如果是想一勞永逸的寫一套UI作為開發時使用的樣式,我建議使用OOCSS來進行開發。但它也有缺點,過多的將設計邏輯放在HTML中,極大的自由化了頁面開發時的選擇,如果寫HTML的開發者不能很好的理解整套CSS的結構,較易在HTML中造成class混亂。

DRY CSS

DRY就是Donot repeat youself 不要重復。但其實這個名字有點無趣,哪個理論不是消除重復呢,但如何消除才是意義所在。總的來說我認為DRYCSS與OOCSS是兩個極端,所以我將會以對比的方式來講講DRYCSS的內容。使用DRYCSS很簡單,三步。

1. 分組可復用屬性

DRYCSS跟OOCSS有點像,第一步都是分組樣式,消除重復,但就像我說的,關鍵在于如何。OOCSS將樣式集合看作對象,所以分組的邏輯是,某個元素本身應該是什么樣的,而DRYCSS則關注重復,無論什么邏輯,只要是一樣的就應該只有一個。其中粒度是值得思考的問題,如果太細,那只會成為一行樣式一組這樣無意義的情況,如果太粗,又會變成毫無復用性的龐然大物。我認為可以將一些有關聯的缺了A時B就沒作用的樣式分為一組,還可以將某些慣用搭配分為一組。下面舉個例子:

{
    float: left;
    position: absolute;
    display: inline-block;
    overflow: hidden;
}

這是一組樣式,可用來觸發Block formatting Contexts(塊級格式化上下文),如此就完成了一組樣式。接著再寫2組關于尺寸的樣式吧。

{
    width: 960px;
    height: auto;
}
{
    width: 720px;
    height: 600px;
}
{
    width: 220px;
    height: 600px;
}

這是三組樣式用來布局,將頁面分為左右兩部分。

2. 按邏輯為分組命名

接著我們來為其命名,其實就是添加一個ID選擇器,但是我們并不真的使用它,而是用來標示該組樣式。下面就來命名上面所分組的樣式。

#BLOCK_FORMATTING_CONTEXTS
{
    float: left;
    position: absolute;
    display: inline-block;
    overflow: hidden;
}

#LAYOUT_FULL
{
    width: 960px;
    height: auto;
}

#LAYOUT_CONTENT
{
    width: 720px;
    height: 600px;
}

#LAYOUT_SIDEBAR
{
    width: 220px;
    height: 600px;
}

這一步類似OOCSS的class,它決定了每組樣式所代表的邏輯或用途,然而DRYCSS多了最關鍵的下一步,也是與OOCSS本質區別。

3. 為各個分組添加選擇器

DRYCSS在使用時和OOCSS有著巨大的差異,在CSS文件中寫入HTML中的class選擇器來使用這些分組后的樣式,而不是直接在HTML中使用CSS文件中寫好的class。

.header,
.container,
.content-right,
.content-left,
#BLOCK_FORMATTING_CONTEXTS
{
    float: left;
    position: absolute;
    display: inline-block;
    overflow: hidden;
}

.header,
.navigator,
.container,
#LAYOUT_FULL
{
    width: 960px;
    height: auto;
}


.content-right,
.section,
#LAYOUT_CONTENT
{
    width: 720px;
    height: 600px;
}

.content-right,
.sidebar,
.profile,
#LAYOUT_SIDEBAR
{
    width: 220px;
    height: 600px;
}

可以看到,使用DRYCSS時,在HTML中所寫的class將會非常表意,元素本身是什么用來做什么,就使用其意義的class命名,而且基本上是一個元素對應一個class,HTML將變的簡單明了。另外DRYCSS也是相對于OOCSS的一種逆向思維,這才是最有趣的地方。在開發中,不應該像OOCSS那樣思考如何應對未來假象的HTML,而是僅僅思考CSS本身。

總的來說,OOCSS適合開發CSS框架或整套UI模版,是自外向內的UI開發方式;而DRYCSS則適合拯救混沌的HTML,或者加強HTML的結構性和表意性,是自內向外的UI開發方式。這里的內指地是HTML結構,外指地是CSS樣式。

SMACSS

這是一個相對繁雜的CSS理論,分為Base、Layout、Module、Status和Theme共五個部分。不過它的核心思想仍然和OOCSS類似,鼓勵使用class。

1. Base 基本屬性

基礎屬性很容易理解,就是最基本的東西,很多樣式簡單的網站都采用一個簡單的二級CSS文件模式,一個base.css通用于所有頁面,而每個頁面有一個特定的CSS文件,我想這就是Base的雛形。要說具體是什么,比如reset文件,再比如放置clearfix或BFC的一些類似工具集的文件。

其實最終會發現,在Base中的CSS屬性將會是幾乎全站都要用到的屬性,但我不想這么描述Base,因為這會誤導人。大多數情況下,在一個網站建立之初也只會有幾個簡單的頁面,于是這幾個頁面都要用到的屬性就變成了通用屬性,但并不是這么簡單的。隨著網站規模的擴大,需求的增加,設計師們靈感的迸發,所謂的通用和統一也在發生著潛移默化。所以在編寫Base時,應該遵循的基準是,哪些樣式是你做下一個網站時也會想用的,哪些樣式即使設計改變了也只需要改變一些數值和顏色,哪些樣式是一些基本原則;而不應該將目前大部分頁面都在使用的樣式放在Base中,還是那個道理,它們也許僅僅是恰好相同,而非邏輯一致。

2. Layout 布局

布局是一個網站的基本,無論是左右還是居中,甚至其他什么布局,要實現頁面的基本瀏覽功能,布局必不可少。SMACSS將這一功能多帶帶提出也是非常正確的,另外還約定了一個前綴l-/layout-來標識布局的class。舉個最普遍的例子。

.l-header {}
    .l-brand {}
    .l-navigator {}
.l-container {}
    .l-sidebar {}
    .l-content {}
.l-footer {}

這就是一個簡單的左右布局,導航和Logo中規中矩在最頂部。

3. Module 模塊

模塊是SMACSS最基本的思想,同時也是大部分CSS理論的基本,將樣式模塊化就能達到復用和可維護的目的,但是SMACSS提出了更具體的模塊化方案。首先表象上來看,SMACSS中的模塊應該擁有一個名字,并且為其class名,而模塊其他class皆以為前綴。比如:

.product {}
    .product-title {}
    .product-image {}
    .product-border {}
    .product-shadow {}

可以看到例子中product是一個模塊,title和image是包含在模塊內的組件,可用可不用;border和shadow是類似OOCSS的附加class用來改變模塊本身。總之,在模塊內可以使用其名稱做前綴任意組織模塊結構,但目前是讓其變得更易用,提高可擴展性和靈活度,如果僅僅為了某些功能而特意寫一些class就有點有形無實的感覺了。

4. State 狀態

狀態經常和JavaScript放在一起使用,它是一種用來標識頁面狀態的class,無論是為用戶標識還是用程序標識。還是一個常見的例子,馬上就明白。active經常用來表示當前的tab,或者當前選中的目標,這就是一種狀態,無論是樣式還是程序都需要知道它。

SMACSS仍然有一個對應的前綴用于標示狀態class,is-是一個合適的詞,指明某一元素是什么狀態。

5. Theme 主題

主題就是皮膚,和OOCSS的分離皮膚與結構不謀而合。更重要的是對于可更換皮膚的站點來說,這樣的分離是非常必要的,只需要更換加載的theme文件即可將皮膚更換。

總的來說,SMACSS是一個較為注意細節與實現的CSS理論,非常適合初涉CSS的人,它可以讓你的CSS跑在軌道上而不至于脫軌。其思想也與OOCSS有很多相通之處,如果沒有適合的方案,我建議新手可以適當的融入OOCSS的思想而使用SMACSS的結構,這樣寫出來的網站樣式至少不會馬上陷入泥沼。

哪一個好用呢?

談了許多的CSS原理,已經有點眼花繚亂,到底哪個好呢?這個問題又歸結到了最佳實踐上,雖然我并不認為有這樣的實踐,但我認為一個項目一定會有適合的實踐,比如前面說的,如果你想做一個CSS框架然后再寫HTML,那就用OOCSS;如果你想先寫HTML或者已經有一個舊的頁面,那DRYCSS應該很適合你;如果新手不知如何下手,那SMACSS可以指導你入門。

無論如何,在我過去很長一段時間的獨立UI開發“生涯”中,這些情況我都遇到過,也有一些自己的想法,我想我將在下一篇博客中談談自己對CSS的理解,并嘗試整理出一些類似理論的東西來。

原文地址:http://www.tychio.net/tech/2014/03/16/css-principle.html

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/110888.html

相關文章

  • 作為前端開發,如何寫好一個簡歷

    摘要:項目地址需求來源通常在各個招聘網站,我們填寫完一些信息后,網站就可以幫助我們生成一個很不錯的簡歷。但是作為一名開發者,尤其是前端開發者,可能對這種簡歷并不滿意。,前端開發神器。最后,為了保護隱私。 背景 前一陣子,閑下來便開始著手做一個一直想做的東西--resume。經過幾天業余時間的折騰,終于做出了一番模樣。Github項目地址:https://github.com/eternity...

    abson 評論0 收藏0
  • 作為前端開發,如何寫好一個簡歷

    摘要:項目地址需求來源通常在各個招聘網站,我們填寫完一些信息后,網站就可以幫助我們生成一個很不錯的簡歷。但是作為一名開發者,尤其是前端開發者,可能對這種簡歷并不滿意。,前端開發神器。最后,為了保護隱私。 背景 前一陣子,閑下來便開始著手做一個一直想做的東西--resume。經過幾天業余時間的折騰,終于做出了一番模樣。Github項目地址:https://github.com/eternity...

    KunMinX 評論0 收藏0

發表評論

0條評論

Yuqi

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<