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還提供了個既強大又坑爹的模板功能。但是感覺很少有人用。不知道是因為操作複雜？不靈活？還是因為生成了一坨一坨注釋？看起來很低階？不知道，反正我也沒有。有幸的是***人幫忙開發了乙個本地程式用來解決html的include問題。dev目錄下的檔案是按照此程式語法要求來寫的。給定乙個module下的url位址，然後自動合併html**，生成pages下的檔案。
HTML與CSS初體驗
html 超級文字標記語言 hypertext makeup language 作用 告知瀏覽器網頁的結構。元素 開始標記 內容 結束標記 例如 這就是乙個元素 css級聯樣式表 cascading style sheets 作用 告知瀏覽器網頁中的元素應該如何表現 屬性 用來指定元素的附加資訊。t...
專案架構的一點猜想
1.資料層 資料層主要是對資料庫的基本操作，並且保證資料連線資源的連線和釋放，避免資料庫死鎖 至於對資料庫的訪問不同的框架有不同的訪問方式，orm,資料直連等，在資料訪問時如何高效，簡潔的獲取期待的結果，才是資料訪問層關心的內容 2.介面定義 描述一組類的公共方法 公共屬性.它不實現任何的方法或屬性...
對架構的一點看法
隨便想到點什麼就隨便寫寫，但是在實踐過程中，以下幾點真的很重要 關於架構 1.所有脫離業務的架構設計都是耍流氓 2.架構設計就是解決問題 權衡利弊的過程 3.權衡是架構逃避不掉的問題。可擴充套件性 業務方需求 效能 現狀 改變代價等的權衡 4.架構一定要有全域性觀 關於能力 1.相比於用過某個軟體某...