關於css框架網頁設計教程

1、框架

關於css框架網頁設計教程

中國的互聯網行業已經發展了10年,瀏覽器也從最早流行的NS到現在的7等等……前端開發工程師的職位也誕生了。近幾年在web開發中,有個非常火的詞——“框架”。YUI、JQuery、Prototype這些javascript框架在開發網站時,確實成爲前端開發工程師的手中利器。爲什麼呢?因爲框架是包含工具、函數庫、約定,以及嘗試從常用任務中抽象出可以複用的通用模塊,讓設計師與程序員避免重複開發。通俗地講便是把大多數重複工作的時間給節約了。

編寫css也是一樣,從最初只是定義文字顏色、內容排版,到現在定義所有的表現。css框架也漸漸被重視了,因爲大家都認識到:從具象的表現中抽出抽象的模塊來重複使用,是減少用戶下載、方便團隊及個人開發最重要的手段。

2、css框架的開發順序

a) 格式

格式化css的真正好處是能夠快速啓動工作,你可以在新的HTML文件裏引入框架,不用再處理重置padding 和 margins,實現統一的排版、瀏覽器下的相同表現。

b) 佈局

定義頁面是二欄還是三欄,是全屏還是1024×768……

一個網站的設計可能有很多種佈局,但是大多數都是由幾個具有複用性的佈局組成,選擇性的引入所需要的佈局,可以很快地應用所期望的頁面佈局。

c) 基本樣式

定義body、h1-h6、a:link-a:active、p等的字體大小和顏色。

基本樣式的css引用,譬如將ul定義class爲“ul-text”,用來展現相同的icon、行間距、鏈接色彩

還可以像這樣應用:class=”ul-text square”,li前展現的是方型的icon。

d) 表格修飾

定義table、tr、td、th、thead、tfoot、tbody、caption等標籤的表現。

和基本樣式一樣,但是表格在現有網站的展現形式幾乎都是處理數據,所以分開存放引用。譬如在table上應用table-style-1便是黑色邊框的表格,table-style-2便是黃色邊框的表格。

e) 表單修飾

定義fieldset、label、button、input 、select、textarea這幾個標籤的表現。

大多數網站的表單、按鈕、輸入框幾乎都是一樣的。之所以引入這個css,是爲了便於統一在各個瀏覽器中的展現。默認的按鈕、輸入框等在各個瀏覽器下的展現區別很大,雖然在格式化的css中已經初步的統一,但是輸入框的邊框,按鈕的樣式都是需要在這個css中定義的。無奈的是select無法做到統一,如果考慮到用js實現的話,這個成本太大了點。

f) 打印修飾

修飾打印輸出的頁面。

g) 包含其他css的css

、、、等等

根據各種引用去引入相應的css。譬如list頁面中沒有需要表格的修飾,那就不引入。以節約代碼量。

3、css框架文件夾的建立

a) core 主要的

存放、、、

b) bud 模塊

存放、、等css

c) petal 具體應用

存放封裝過的css。、、、等css。這個文件夾存放的css都是被直接引用的。

文件夾的命名,按個人喜好啦!

4、css框架的優點

a) 提高開發效率。

b) 規範名稱定義,便於維護。

c) 規範項目開發流程

d) css代碼更清晰、簡單。html代碼更合理。

5、css框架的.弊端。

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帶給用戶最好的感受。