當前位置:才華齋>設計>網頁設計>

關於css框架網頁設計教程

網頁設計 閱讀(1.67W)

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