個人總結了在開發css框架中的一點經驗，獻醜了。希望大家的討論能讓我們共同進步。 :)
1、css框架
中國的互聯網行業已經發展了10年，瀏覽器也從最早流行的NS到現在的FF3.IE7等等……前端開發工程師的職位也誕生了。近幾年在web開發中，有個非常火紅的字——「框架」。 YUI、JQuery、Prototype這些javascript框架在開發網站時，確實成為前端開發工程師的手中利器。為什麼呢？因為框架是包含工具、函數庫、約定，以及嘗試從常用任務中抽像出可以重複使用的通用模組，讓設計師與程式設計師避免重複開發。通俗地講便是把大多數重複工作的時間給節約了。
寫css也是一樣，從最初只是定義文字顏色、內容排版，到現在定義所有的表現。 css框架也漸漸被重視了，因為大家都體認到：從具象的表現中抽出抽象的模組來重複使用，是減少使用者下載、方便團隊及個人開發最重要的手段。
2、css框架的開發順序 a) 格式化reset.css
b) 佈局layout.css
基本樣式的css引用，譬如將ul定義class為“ul-text”，用來展現相同的icon、行間距、鏈結色彩。
還可以像這樣應用：class=”ul-text square”，li前展現的是方型的icon。
和基本樣式一樣，但是表格在現有網站的展現形式幾乎都是處理數據，所以分開存放引用。譬如在table上應用table-style-1便是黑色邊框的表格，table-style-2便是黃色邊框的表格。
大多數網站的表單、按鈕、輸入框幾乎都是一樣的。之所以引入這個css，是為了方便統一在各個瀏覽器中的展現。預設的按鈕、輸入框等在各個瀏覽器下的展現區別很大，雖然在格式化的css中已經初步的統一，但是輸入框的邊框，按鈕的樣式都是需要在這個css中定義的。無奈的是select無法做到統一，如果考慮到用js實現的話，這個成本太大了點。
g) 包含其他css的css
a) core 主要的
存放reset.css、layout.css、type.css、print.css
存放table.css、form.css、album .css等css
存放封裝過的css。 frontpage.css、llist.css、detail.css、register.css等css。這個資料夾存放的css都是被直接引用的。
a) 提高開發效率。
b) 規範名稱定義，方便維修。
c) 規範專案開發流程
d) css程式碼更清楚簡單。 html代碼更合理。
a) 學習成本提高。你需要了解整個框架，需要閱讀框架的文檔。
b) css框架對於一個小型專案等頁面來說很臃腫。框架中可能有大部分你用不到的程式碼。
c)可能會無法幫助你的技術提升。太依賴框架，以至於很難排除bug。包括框架中本身就帶的bug。
d) 選擇自己需要的框架與開發框架都很痛苦。寫到後面發現越來越不靈活，越來越臃腫。殘念 -_-
6、開發及使用css框架中常遇到的問題。
1、頁外引用樣式過多。
譬如關於ul的margin定義,在格式化的css中會聲明為0，而在基本樣式的css中又可能會聲明margin:5px 10px;
所以在Yslow中會出現多次定義。
2、組件復用性的考量。
譬如表單定義的css中定義了所有表單的修飾,而假定在註冊這個頁面中只是需要這個css的百分之三十。那是否要切割出去那不要的百分之七十?
綜合以上的二個問題，個人認為解決的方式便是封裝，讓該有的有，不該有的沒有。盡量減少http連線數和css的大小。但如果徹底是這樣做的話，css的複用性又會變得很差，後期手工的封裝會很痛苦。只能套用小馬的一句話「具體情況，具體分析」。人生真是矛盾啊…
3、到底該不該支持em?
可見如要支持em，最大的目的是為了在瀏覽器中可以根據用戶的分辨率大小自由縮放，對於擁有超大顯示器的用戶與小顯示器的使用者是非常有用的。但在採集我們用戶的瀏覽器資料後，發現分辨處於這二端的用戶非常少，可想而知，為這部分的用戶多花比正常開發一倍以上的時間顯然是件不划算的事情，所以當初在開發tbsp的時候，我們團隊就決定了不支持em。當然這是個建議，我們也希望能使用em帶給使用者最好的感受。
以上六點就是我和整個淘寶UED團隊在日常開發中的思考與總結 ，可能您會提出一些不同的觀點，沒關係，給我們留留言，一起探討吧！
以上就是CSS教學關於css框架網頁設計的內容， 更多相關文章請關注PHP中文網（m.sbmmt.com）！
