HTML文檔結構對Div+CSS布局的意義

表單提交中get和post方式的區別有5點
1.get是從服務器上獲取數據，post是向服務器傳送數據。
2.get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中可以看到。post是通過HTTPpost機制，將表單內各個字段與其內容放置在HTML HEADER內一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3.對於get方式，服務器端用Request.QueryString獲取變量的值，對於post方式，服務器端用Request.Form獲取提交的數據。
4.get傳送的數據量較小，不能大於2KB。post傳送的數據量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。
5.get安全性非常低，post安全性較高。

HTTP請求：get與post方法的區別
HTTP 定義了與服務器交互的不同方法，最基本的方法是 get 和 post。事實上 get 適用於多數請求，而保留 post僅用於更新站點。根據 HTTP 規范，get 用於信息獲取，而且應該是安全的和冪等的。所謂安全的意味著該操作用於獲取信息而非修改信息。換句話說，get 請求一般不應產生副作用。冪等的意味著對同一 URL的多個請求應該返回同樣的結果。完整的定義並不像看起來那樣嚴格。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。反之亦然。post請求就不那麼輕松了。post 表示可能改變服務器上的資源的請求。仍然以新聞站點為例，讀者對文章的注解應該通過 post請求實現，因為在注解提交之後站點已經不同了（比方說文章下面出現一條注解）；
在FORM提交的時候，如果不指定Method，則默認為get請求，Form中提交的數據將會附加在url之後，以?分開與url分開。字母數字字符原樣發送，但空格轉換為“+“號，其它符號轉換為%XX,其中XX為該符號以16進制表示的ASCII（或ISOLatin-1）值。get請求請提交的數據放置在HTTP請求協議頭中，而post提交的數據則放在實體數據中；
get方式提交的數據最多只能有1024字節，而post則沒有此限制。
在表單裡使用”post”和”get”有什麼區別
在Form裡面，可以使用post也可以使用get。它們都是method的合法取值。但是，post和get方法在使用上至少有兩點不同：
1、get方法通過URL請求來傳遞用戶的輸入。post方法通過另外的形式。
2、get方式的提交你需要用Request.QueryString來取得變量的值，而post方式提交時，你必須通過Request.Form來訪問提交的內容。
仔細研究下面的代碼。你可以運行之來感受一下：
代碼
〈!–兩個Form只有Method屬性不同–〉
〈FORM ACTION=“getpost.asp” METHOD=“get”?
〈INPUT TYPE=“text” NAME=“Text” VALUE=“Hello World”〉〈/INPUT〉
〈INPUT TYPE=“submit” VALUE=“Method=get”〉〈/INPUT〉
〈/FORM〉
〈BR〉
〈FORM ACTION=“getpost.asp” METHOD=“post”〉
〈INPUT TYPE=“text” NAME=“Text” VALUE=“Hello World”〉〈/INPUT〉
〈INPUT TYPE=“submit” VALUE=“Method=post”〉〈/INPUT〉
〈/FORM〉
〈BR〉
〈BR〉
〈% If Request.QueryString(“Text”) 〈〉 ““ Then %〉
通過get方法傳遞來的字符串是： “〈B〉〈%= Request.QueryString(“Text”) %〉〈/B〉“〈BR〉
〈% End If %〉
〈% If Request.Form(“Text”) 〈〉 ““ Then %〉
主要就是我對結構和開發效率之間的矛盾的一個思考，CSS框架怎樣才能不破環結構的一個疑問。而且對於結構和效率我的觀點就是“擁有合理的結構，才是你web標准化的根本動機”，web是承載信息的，沒有理由為了視覺效果，而破壞合理的結構。 

　　Web標准的要把握幾點：

　　使用結構化，語義化的標簽
　　使用CSS分離出（X）HTML文檔中的表現元素
　　依靠javascript去增強，而不是替代，網站的特征（舉個例子就是如果css做不了的，交給Javascript而不是替代css去做他能做的）

　　對於多樣式組合的結構我一直是很反感的，可能我理解的不夠深入，體會不到他的好處，或許合理的組合可以兼顧結構和開發效率，可是我沒有發現，我就要抵觸。

　　對樣式組合方式是這樣的
　　<div class=”class1 class2 … classn”></div>
　　舉個布局例子
　　<div class=”f-left w400 bgfff”>
　　幾個類組合成一個左浮動，寬400 背景為白色的一個區域

　　你可能擁有一個龐大的庫，頁面只需要任意的class的組合就可以完成，省去大部分花費在css上的時間，可是帶來的是結構的混亂，改版的困難，甚至向後兼容受到限制。這樣做和table布局沒什麼兩樣，只是代碼看著好看而以，而且代碼量相差也不會太大。在應用web標准初期，合理的table布局也是允許的。

　　如此多的class讓我想起了table冗長的屬性

　　<TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=CENTER WIDTH=100% HEIGHT=100%>

　　難道辛辛苦苦就是想使用div配合css模擬出一個table很容易實現的效果？而且達到和table布局一樣的拙劣？

　　語義化也是結構的一個部分，語義除了合理的使用（X）HTML標記語言，id也是一個語義組成的部分，div的id就像一個即時貼，告訴你某個div的語義，告訴你這個區塊的意義。

　　微格式（Microformat）是在標准 XHTML 代碼中嵌入結構化數據的一種新方法。他的誕生也很明確的說明了web的結構永遠是第一位，語義化的優勢很現實的體現出來，div的屬性規劃也體現著語義，而不僅僅是一個傳遞給樣式工作的接口。可以去看看ibm文檔中心的一篇“使用 microformats 分離數據與格式”了解它的工作原理。