從GMail認識的W3C網頁標準和Ajax

不可否認，W3C網頁標準剛出來的時候的確很吸引人。那時因為firefox的出現，衝擊了瀏覽器市場，使得大家為了一個小狐狸，而掀起一場網頁標準的風波，但是對於設計師來說帶來什嗎？在這場風波我看到的最多就是技術的泛濫。 　　和一些designer聊天，第一句話就問，“你的網頁標準化了”嗎，“你的網頁又有幾處錯誤”。無形中這些話就給我們這些designer來說帶來很大壓力。每次更新網頁都很害怕因為一些小小的改動導致一些小錯誤。似乎W3C成了一種追捧現象。就如同前段時間的Ajax熱一樣。但我們更加是應該理性分析，我們什麼時候才應該用到這些技術。 我舉一些例子 1.Div和Table之間的誤會 　　 　　剛開始接觸到W3C的時候，首先面臨的問題是要把傳統的table布局給去掉，利用Div+CSS做結構。這個是網頁標準化的精髓。但是問題來了，大部分人都因為這個而誤會說 "Table沒有用了" "你的網頁還有table阿，out了"。其實不然，如果這樣想，那就大錯特錯了。W3C只是要求不用table布局，沒有說table不標準呀。 　　每一個web標籤都有它存在的意義，不是說完全遺棄某個標籤。我們應該合理利用好每一個標籤，table並沒有被放棄，相反的table只是回到他的本職工作---用來顯示資料，當你要在網頁上顯示大量的表格式資料的時候，就應該用table了，這樣你可以花最少的時間，達到最好的效果。假如你一定要用<ul><li>來類比<table>也可以，但是你將因此耗費過多時間在CSS上面，增加很多多餘的代碼量，而且還不一定能達到你想要的效果。 　　最有說服力網站:GMail 你說它不標準嗎？不是，你說它全是Div+CSS嗎，也不是。它是Div+CSS+Table結構，它合理了利用好了每個網頁標籤。嚴格來說GMail並沒有按照W3C XHTML 1.0標準去做。首先，它的網頁沒有用到 XHTML 1.0　的過渡定義。因為它沒有辦法用，如果用了這個定義去設計GMail。估計大家看不到那麼出色的程式了。即使沒有用這個標準定義，但是它的CSS能寫出這麼好的相容性也是一種最大的成功。 2.Ajax我們是否真的需要 　　最先帶出這個話題的是GMail，這個時候就開始很多人開始研究這個老技術的混合體。現在也開始在泛濫，但是很多時候我們不需要Ajax。簡單的說，對於一個普通網站來說，你要宣傳就必須要讓搜尋引擎找到你，但是Ajax最大的問題就是搜尋引擎無法判斷你裡面的內容。就算你的技術多麼成熟，做出來的東西不方便宣傳，那也是一種失敗。 　　Ajax的主要是為提高程式的易用性為主，所以很多時候都會應用在背景程式中(當然部分操作也可以應用到前台)。來增強程式的人性化，以及易用性。 　　Ajax最主要是實現了非同步更新的功能，這樣使網頁不用同步顯示更多資訊。有效減輕了伺服器的負擔。而實現非同步主要是因為Javascript，而不是XML。為什麼這樣說呢，沒有XML，Javascript同樣可以實現非同步。但是沒有Javascript，光有XML也沒用。XML只是作為一種資料來源。我分析了GMail的代碼很長一段時間了，又一點很讓我感到很奇怪，GMail用到XML的地方其實很少。它主要還是利用了大量的 Javascript。裡面用得最多的是Javascript和iframe，它解決Js回退靠的是iframe、輸出郵件，它直接輸出了 Javascript代碼到一個iframe的頁面裡面(直接看代碼就可以看到)，然後又利用Javascript重新構造這些JS數組，然後輸出到網頁上。中間的JS數組其實已經是直接寫到了頁面的，這樣的過程用到的XML就很少了。整個GMail用得最多的是非同步JS方式。這樣一來GMail也是傳統，都是架構在利用JS控制著這個網頁。而不是我們現在很多Ajax程式，一個頁面上全是讀XML,這樣的方式是比較愚蠢的。 　　我們要做的是利用好Ajax裡面的 Javascript ，而XML只能作為必要的輔助。 　 　　呵呵，文章結束了，以上均是我工作中遇到的問題的一些總結性的看法。希望大家不要因為這兩個技術而“誤入歧途”，重要的是理智考慮我們的網頁如何給這兩個技術一個合理的位置。 　　最後，希望有能力的朋友多去研究研究GMail，你會發現很多和業界炒作的所謂新技術有很多出入。 　　我對GMail的評價是一個很合理利用了以上兩點技術的一個很成功的傳統程式。

~

不可否認，W3C網頁標準剛出來的時候的確很吸引人。那時因為firefox的出現，衝擊了瀏覽器市場，使得大家為了一個小狐狸，而掀起一場網頁標準的風波，但是對於設計師來說帶來什嗎？在這場風波我看到的最多就是技術的泛濫。 　　和一些designer聊天，第一句話就問，“你的網頁標準化了”嗎，“你的網頁又有幾處錯誤”。無形中這些話就給我們這些designer來說帶來很大壓力。每次更新網頁都很害怕因為一些小小的改動導致一些小錯誤。似乎W3C成了一種追捧現象。就如同前段時間的Ajax熱一樣。但我們更加是應該理性分析，我們什麼時候才應該用到這些技術。 我舉一些例子 1.Div和Table之間的誤會 　　 　　剛開始接觸到W3C的時候，首先面臨的問題是要把傳統的table布局給去掉，利用Div+CSS做結構。這個是網頁標準化的精髓。但是問題來了，大部分人都因為這個而誤會說 "Table沒有用了" "你的網頁還有table阿，out了"。其實不然，如果這樣想，那就大錯特錯了。W3C只是要求不用table布局，沒有說table不標準呀。 　　每一個web標籤都有它存在的意義，不是說完全遺棄某個標籤。我們應該合理利用好每一個標籤，table並沒有被放棄，相反的table只是回到他的本職工作---用來顯示資料，當你要在網頁上顯示大量的表格式資料的時候，就應該用table了，這樣你可以花最少的時間，達到最好的效果。假如你一定要用<ul><li>來類比<table>也可以，但是你將因此耗費過多時間在CSS上面，增加很多多餘的代碼量，而且還不一定能達到你想要的效果。 　　最有說服力網站:GMail 你說它不標準嗎？不是，你說它全是Div+CSS嗎，也不是。它是Div+CSS+Table結構，它合理了利用好了每個網頁標籤。嚴格來說GMail並沒有按照W3C XHTML 1.0標準去做。首先，它的網頁沒有用到 XHTML 1.0　的過渡定義。因為它沒有辦法用，如果用了這個定義去設計GMail。估計大家看不到那麼出色的程式了。即使沒有用這個標準定義，但是它的CSS能寫出這麼好的相容性也是一種最大的成功。 2.Ajax我們是否真的需要 　　最先帶出這個話題的是GMail，這個時候就開始很多人開始研究這個老技術的混合體。現在也開始在泛濫，但是很多時候我們不需要Ajax。簡單的說，對於一個普通網站來說，你要宣傳就必須要讓搜尋引擎找到你，但是Ajax最大的問題就是搜尋引擎無法判斷你裡面的內容。就算你的技術多麼成熟，做出來的東西不方便宣傳，那也是一種失敗。 　　Ajax的主要是為提高程式的易用性為主，所以很多時候都會應用在背景程式中(當然部分操作也可以應用到前台)。來增強程式的人性化，以及易用性。 　　Ajax最主要是實現了非同步更新的功能，這樣使網頁不用同步顯示更多資訊。有效減輕了伺服器的負擔。而實現非同步主要是因為Javascript，而不是XML。為什麼這樣說呢，沒有XML，Javascript同樣可以實現非同步。但是沒有Javascript，光有XML也沒用。XML只是作為一種資料來源。我分析了GMail的代碼很長一段時間了，又一點很讓我感到很奇怪，GMail用到XML的地方其實很少。它主要還是利用了大量的 Javascript。裡面用得最多的是Javascript和iframe，它解決Js回退靠的是iframe、輸出郵件，它直接輸出了 Javascript代碼到一個iframe的頁面裡面(直接看代碼就可以看到)，然後又利用Javascript重新構造這些JS數組，然後輸出到網頁上。中間的JS數組其實已經是直接寫到了頁面的，這樣的過程用到的XML就很少了。整個GMail用得最多的是非同步JS方式。這樣一來GMail也是傳統，都是架構在利用JS控制著這個網頁。而不是我們現在很多Ajax程式，一個頁面上全是讀XML,這樣的方式是比較愚蠢的。 　　我們要做的是利用好Ajax裡面的 Javascript ，而XML只能作為必要的輔助。 　 　　呵呵，文章結束了，以上均是我工作中遇到的問題的一些總結性的看法。希望大家不要因為這兩個技術而“誤入歧途”，重要的是理智考慮我們的網頁如何給這兩個技術一個合理的位置。 　　最後，希望有能力的朋友多去研究研究GMail，你會發現很多和業界炒作的所謂新技術有很多出入。 　　我對GMail的評價是一個很合理利用了以上兩點技術的一個很成功的傳統程式。