項目中選擇css框架的苦惱

優勢
a) 提升開發效率。
b) 規範名稱定義，便於維護。
c) 規範項目開發流程
d)css代碼更清晰、簡單。html代碼更合理。
e) 大規模項目中能夠減小用戶下載
弊端
a) 學習成本提升。你須要瞭解整個框架，須要閱讀框架的文檔。
b)css框架對於一個小項目等頁面來講很臃腫。框架中可能有大部分你用不到的代碼。
c)可能會沒法幫助你的技術提升。太依賴框架，以致於很難排除bug。包括框架中自己就帶的bug。
d) 選擇本身須要的框架與開發框架都很痛苦。寫到後面發現愈來愈不靈活，愈來愈臃腫。
常見問題
一、頁面外部引用樣式過多。
譬如關於ul的margin定義,在格式化的css中會聲明爲0，而在基本樣式的css中又可能會聲明margin:5px 10px;
因此在Yslow中會出現屢次定義。
二、組件複用性的考量。
譬如表單定義的css中定義了全部表單的修飾,而假定在註冊這個頁面中只是須要這個css的百分之三十。那是否應切割出去那不要的百分之七十?
綜合以上的二個問題，我的認爲解決的方式即是封裝，讓該有的有，不應有的沒有。儘可能減小http鏈接數和css的大小。但若是完全是這樣作的話，css的複用性又會變得不好，後期手工的封裝會很痛苦。
三、到底該不應支持em?
可見如要支持em，最大的目的是爲了在瀏覽器中能夠根據用戶的分辨率大小自由縮放，對於擁有超大顯示器的用戶與小顯示器的用戶是很是有用的。但是在採集咱們用戶的瀏覽器數據後，發現分辨處於這二端的用戶很是少，可想而知，爲這部分的用戶多花比正常開發一倍以上的時間顯然是件不划算的事情，因此當初在開發tbsp的時候，咱們團隊就決定了不支持em。固然這是個建議，咱們也但願能使用em帶給用戶最好的感覺。