html與css架構的一點體驗

css自己，能夠說是一門很是簡單而容易入門的語言。製做一個頁面，或者製做一個小企業站，對於css的要求都是很是低的。只要熟悉語法，經過英文單詞的含義猜，都基本能夠拼出一套樣式。更況且市面上還有各類各樣的輔助軟件。

 

若是是一個比較大的網站，對css架構的要求就會相對高一些。好比，有一些能夠公用的部分，能夠提取出作模塊。這個就是所謂的模塊化。

 

模塊化有什麼優勢呢？

 

在不去google各類結果的狀況下，我腦殼中能反應到的主要有如下幾點：

1，減小無心義的開發工做量——不須要複製粘貼某段樣式代碼到其餘文件。

2，代碼容易維護。若是模塊樣式有變動，只須要修改一個css文件便可。

3，配合對應的註釋和目錄結構，會讓整個項目的html和css代碼看起來更清晰。

 

可是模塊化有時候就很糾結了。

在實際開發維護一個網站的過程當中，html提供的模塊，一般是按照功能來維護的。可是通常所謂css的模塊化，是按照UI呈現來作的模塊，模塊的劃分標準並不統一。

對於css自己的整理，咱們會但願按照css來劃分模塊。可是對於html，包括提供給下游部門進行開發時，固然要提供html模塊。他們並不關心css具體是如何劃分和整合的。

 

因而，有了下面這種想法：

css分爲5層結構

 

base層——是一些全站公用的基礎樣式和基礎模塊樣式層（我把清0包括在這裏了）。這個層至關於按照UI呈現來劃分了模塊。若是配合良好的UI規範，也能夠保證整站的基礎模塊UI呈現一致。在大網站來講，這點應該是專業UI設計須要保證的。若是靠譜的話，base層甚至能夠開發成一個網站的樣式核心包。

 

module層——是功能模塊樣式層。這部分的css是由基礎模塊樣式和非公用樣式2部分組合而成的。

 

patch層—— 是補丁層。在用功能模塊拼合頁面的時候，將邊距和其餘一些模塊中沒法包含的樣式放在patch中。（好比某個頁面忽然要求增長一個banner之類的）

 

pages層——是個是用import方式將module層和patch層的東西引入到頁面的樣式表文件。配合能夠合併css的軟件（能夠google下關鍵字Merge能夠搜到一些），將全部import的文件壓縮在這個pages文件中上線。

 

tag層 —— 最上面的tag至關於實際壓縮後上線的css代碼，並不消耗開發成本。這樣基本能夠保證每一個頁面css的http請求只有1個。又能夠知足本地模塊化開發。

 

html對應的結構

 

html至關於分爲4層。

base層 —— 對應css的base層。是整個UI規範樣式和規範樣式html代碼的一個參考文件。

module層——對應css的module層。能夠提供給其餘開發人員，裏面要寫全該模塊的全部狀態。這樣既能夠保證後臺開發人員很方便的找到某個功能的代碼，又解決了有時候提供一個完整頁面要犧牲掉部分狀態的狀況。好比一個按鈕有2種狀態，若是都放在頁面上，頁面就容易走樣。若是不放在頁面上，又不方便後臺工程師開發。固然以前我是把其餘狀態寫註釋的方式寫在頁面上的，可是仍然有問題，就是常常須要去重複 註釋/取消註釋 這種無心義的勞動。

pages層——就是拼好的頁面。module既然已經提供了具體的代碼給後臺的工程師們，那pages幹啥呢？它存在的意義是告訴本身和其餘人，每一個模塊須要放置的位置。還有提供宏觀的預覽。沒有預覽，老是不爽的吧！

 

dev層——其實這個是個純開發用的。各類後臺語言都有include能夠用來管理公用模塊。可是html卻沒有。爲此DW還提供了個既強大又坑爹的模板功能。可是感受不多有人用。不知道是由於操做複雜？不靈活？仍是由於生成了一坨一坨註釋？看起來很低級？不知道，反正我也沒有。有幸的是xxx人幫忙開發了一個本地程序用來解決html的include問題。dev目錄下的文件是按照此程序語法要求來寫的。給定一個module下的url地址，而後自動合併html代碼，生成pages下的文件。