1、我用Html進行設計
曾經我以為我蠻特別的，我喜歡用記事本來寫很簡單很簡單的Html。而且，我看的關於網頁的第一個教程也就是教你<h1>啊這些標簽的教程。相信那個著名的教程，很多人都有看過。只是很多看過了之後不一定會自己去手寫這些代碼，只是知道FrontPage這樣的工具背後的原理就好了。
但是時間久了還是覺得蠻累的。因為我寫代碼的時候畢竟是要靠自己的大腦去想象最終的外觀會是什麼，所以有的時候還是蠻想去用Dreamweaver這樣的工具。也難怪那些所見即所得的工具會有那麼多用戶了，因為寫的時候就直接看到了最終的呈現。手寫代碼的時候，如果遇到了重要的內容，我會用<font>這樣的標簽特意去改變一下外觀。遇到了列表的內容的時候會用<ul>啊這樣的標簽，產生1234的標號，或者一個個的圓點。其實有的時候覺得Html挺簡單的，因為標簽的數量很有限嘛。
2、我使用Html的表格
Html的表格是很有意思的東西。當你遇到了要列表的東西的時候，如果是沒有表頭而且是一列的時候，你可能會用<ol>這樣的單列。如果是兩列，可能就會用<table>了。而且用起來也不是很復雜，<tr>就是開一行，<td>就是一列。當然還有很多種排法了。基本的也就是分方格，然後放東西。表格有趣的地方是，你設計form這樣的東西的時候也會用表格。雖然每個單元格的內容之間沒有什麼意義上的關聯了。不像你的成績單列表那樣，數學成績一列，語文成績一列。在form中使用表格僅僅是為了最終的版式上的問題。利用單元格把form中的元件進行定位。後來表格的排版作用用到了整個頁面的排版，而且越用越復雜，表格加表格。直接導致了我這樣手寫代碼的人無法去修改，去編寫這樣的頁面。一度讓我很傷心，覺得這個世界被Dreamweaver這樣的工具的使用者掌握者，因為只有利用所見即所得才能夠去設計這樣外觀豐富的主頁。
3、我還用過CSS
css是讓我激動的東西。我承認這點。我曾經夢想，我寫網頁的時候只要把每塊內容指定好了class。以後要改變網頁的外觀就只需要把css換調就可以了。而且css可以是內含的也可以是外部用<link>鏈接的。我要把網站改版把css的內容換一下就可以了。而且css還有@import，利用它我還可以在網站的每個目錄下都放一個style.CSS，然後利用@import包含站點的樣式表。這樣每個網頁就不用..這樣的目錄選擇符來選擇在父目錄中的樣式表了。這個特性著實讓我很興奮。我的夢想越來越清晰，就是有朝一日，我寫的網頁能夠很輕易的更改外觀，而且編寫的時候再也不用自己去使用<font>這樣的標簽了。
4、Javascript也是讓人好奇的東西
我相信網絡發展還不如現在這麼發達的時候就開始設計網頁的朋友，一定對於各式各樣的Javascript非常熟悉。比如跟隨鼠標的星星，跑馬燈之類的東西。javascript設計出來是為了實現客戶端的一定交互性的。javascript之所以能夠交互是因為，它能夠通過DOM操縱你看到的html頁面，而且能夠通過html元素中的事件屬性得到你的輸入。因為Javascript能夠通過DOM把html的頁面進行改變。這個性質其實也讓我激動了好久。比如leoboard的最新帖子這樣的信息，就是通過一個<script>的鏈接，鏈接到一個CGI上面，它產生的就是一段JS腳本，通過document的函數寫出一段html代碼。也就是說，Javascript能夠"動態"的產生Html代碼。由於javascript的這個功能，我又開始做夢了。希望能夠整個網站都是通過互相包含的Javascript組成。我把我的內容都寫在Javascript的變量之中，然後通過一定規則組合通過DOM的函數把內容以一定的模板風格寫入到最終的Html輸出之中。
5、再聞CSS
一開始聽說css，也許那個時候還是css1的時代吧。只知道css能夠設定一定元素的外觀顯示，比如字體啊，空白什麼的。關於css的排版功能一概不知。第一次做css的夢的時候，其實就是因為要把html進行排版控制，不得不用很多的table這個原因破滅的。所以當我知道css的功能很強大，可以進行各種版面控制的時候，就又開始做夢了。把內容按照其性質放到一些<div class="...">這樣的標簽之中，用不同的CSS樣式表，能夠把這些div定位到頁面的不同地方，而且顯示也是不一樣的。這樣我就能夠在寫Html的時候以任意的順序來寫，只管內容。而css會根據你對內容的描述（class是什麼）把內容進行定位排版和顯示。所以說，以前我知道的css只把元素的內容和顯示分開了，但是元素的位置還是與在源代碼中的位置相關。而現在知道的css，能夠讓元素只管自己的事情，告訴CSS自己是什麼（class是什麼），不用再考慮自己在文檔中的位置了。這樣不就實現了內容與表現分離了嗎？不就是我等用記事本寫網頁的網頁設計者追求的嗎？
6、內容與外觀分離
我相信這句話很多人都聽說過，夢想過。我的夢從模糊，到清晰，一直都在想著有朝一日我能夠只管把我要傳達的內容寫下來，讓其他的人來給我排版給我定外觀。It is a Dream。我們只從一個網頁設計者的角度，而且是一個普通網頁設計者的角度來談這個問題。不要把什麼中間件，應用服務器什麼程序高手津津樂道的術語來壓"我們"。為什麼要把內容和外觀分離我相信很多人都有自己的體會。我的體會很簡單。當年自己手寫html的時候，我對我的內容很有信心，我知道我要說什麼，我有內容。但是我對於如何排版很沒有信息，我想讓別人，或者自己以後來把內容進行排版。但是事情是很讓人失望的，我基本上只有兩個對策。把內容的格式變得簡單得不能再簡單，只是Html的最基本元素的線性排列。除了<p>就是<p>這樣的頁面，樸素得不能再樸素。要麼就是設計一個很好看，很復雜的頁面。我自己手工的把內容粘貼到頁面的模板之中去。如果有很多類似的網頁，還要保證它們的風格是一致的。如果每個頁面還有到其他頁面的鏈接，比如是上一頁，下一頁之類的，It is a nightmare。把內容與外觀分離，就這樣成為了我16歲的夢想。
7、perl，PHP，ASP
我很坦白，我從來沒有用過JSP，我不喜歡Java提供的那些東西（請不要因此罵我淺薄，我知道它們的商業價值，但是現在僅僅是說網頁設計）。按照順序，我用過的是這麼三種網絡腳本。perl是我接觸的最早的一個網絡腳本，那個時候一般都是用CGI這個名字。後來我有遇到了PHP，最後才是ASP。這裡我只是談網頁的問題，不涉及到這些網絡腳本怎麼實現網絡的交互的。也只是就著網絡腳本，說說它們怎麼又能實現內容與外觀分離的。而且這三種雖然在訪問文件，訪問數據庫，使用模板，產生html輸出各個階段和模塊上各有不同，但是原理一樣，方法相似，所以通稱網絡腳本。網絡腳本是讓我激動的東西，而且同樣作為engine驅動著很多現在正在運行的網站，比如經典的LAMP組合。它們關鍵的地方是能夠產生html輸出。因為html不再是你自己手寫的了，所以不需要經過你的手就能把Html的輸出產生變動，這樣就有靈活性。為了文章能夠分出更多的節，我按照我個人的認識順序來看看網絡腳本使用
8、網絡腳本和文件
我最先看到網絡腳本的使用，是leoboard這樣的cgi程序，它使用文本作為數據的存放媒介。數據來源是文本，然後cgi中的perl程序會對文本進行解析，然後把解析的結果可能會放到變量之中，最後變成html的輸出。這裡就是通過CGI程序作為中介，把文本的內容表現到了Html之中。
9、網絡腳本和數據庫
後來我才看到了網絡腳本和數據庫的連用。經典的搭配有PHP+MySQL和ASP+Access，我都有用過，不過都是很簡單的。把數據儲存在數據庫中好處當然是多多，專業人士可以有很多事務啊之類的術語來描述其好處。不過顯而易見的是，儲存和獲取的方法是標准化的，通過SQL嘛。而用文本作為存放媒介，文件格式以及解析，還有文件的完整性，容錯這些都需要網絡腳本設計者自己來控制，雖然很自由，但是更多的是勞累。同樣，一種腳本有自己的一種格式，多浪費。要換論壇程序這樣的情況出現的時候，又需要了很多麻煩。
10、網絡腳本和模板
我記得當時我學asp的時候，很多文章就是這麼介紹的。ASP能夠夾雜在html的代碼之中，可以很方便的使用。而我使用perl的cgi的時候，很多程序又是使用滿是$xxx的模板來做html輸出的。這個時候，我就想who is better？模板我還是蠻欣賞的。初級階段的模板就是很多以前的CGI的網絡文章程序中的那樣，在html中放perl的變量名，然後最後輸出的時候做一個替換。現在的模板當然要復雜好多，理論也很多。但是，我們可以看到的一點是模板做到了"把業務邏輯和表現邏輯分離"。一般模板和腳本的關聯就是通過一些兩方面都知道名字的變量或者數組。然後腳本在變量中預先把內容存入這些變量之中，模板再把變量和數組中的內容提取出來插入到html之中。由於模板大部分是由Html組成，所以比較適合給設計人員來設計。而且腳本的任務也就僅僅致力於從數據庫也好，文本也好，這樣的數據源中取出內容，進行一些加工，然後存入到變量之中。至少讓腳本程序員免於考慮最終的外觀問題。
11、網絡腳本的時代
我們現在基本上就處在這麼一個時代之中，大部分的頁面已經不是手工編寫的Html了。而是由網絡腳本動態產生的。方法步驟都是類似的：數據源+網絡腳本+模板=頁面。似乎故事已經到了終結了。因為美夢已經成真了。利用數據庫中存放數據，模板來控制顯示，網絡腳本進行一些計算和溝通工作，內容和外觀分離的夢想已經實現了。而且，現下的很多現成的程序，一些CMS（內容管理系統），你直接在服務器上安裝好，就能夠享受其便利了。但是，我們還有更多選擇。
12、XML的登台
XML應該不是什麼陌生的東西了。如果你不知道，說明你可能已經很久都沒有關心過網頁設計或者說是計算機這個行業了。XML的好處，長處，已經被說爛了。我就不多說了。
我把XML分為兩類：作為數據或者文檔的XML，以及功能性的XML。這個分類是我自己下的，功能性的XML指的就是HTML，SVG，MathML這些。可能SVG什麼的你不了解，但是至少HTML你知道吧。關於HTML也是XML這個觀點，你應該聽說過。HTML為什麼被我說成功能性的XML呢？因為如果你浏覽器為觀點，它認識HTML，它能夠把HTML標記的能內容作出顯示。而如果是一般的XML，它就不認得，如果是IE會調用內部的一個顯示XML的模板把它顯示出來，但是有的浏覽器就不會。也就是說，一般的XML其中的內容元素，對於浏覽器來說它是不知道什麼意義的，而Html的元素是對浏覽器有特殊意義的。同樣，SVG這些XML也是這樣，雖然標准仍然在制定之中，浏覽器對它的支援還需要一些插件。但是SVG的基本結構不會有什麼變動了，它就是通過標簽的標記，通過浏覽器的讀取產生二維的圖像。關鍵的地方就是，浏覽器認得SVG中的元素，知道它的意義，並且能夠作出顯示。
自然，對於浏覽器沒有特殊意義的XML就是文檔數據型的。把XML分為文檔為中心和數據為中心的這種分法是非常常見的。關於這個話題，我在後面繼續說。
13、Html作為一種功能性的XML
我現在把HTML完全作為一種表現語言，它的唯一功能就是把內容作出顯示。也就是我把在HTML中表現內容的語意這個夢想給完全放棄了。HTML就是一個功能性的XML，它的目的就是讓浏覽器顯示。要把內容和表現分離，我就是要從別的數據源中轉換到HTML。那是不是CSS就多余了？當然不會，css的目的是幫助HTML更好的表達如何顯示這個要求。也就是XHTML+CSS共同表達的一個目的，網頁的外觀布局。它們的目的是一致的，而不是我以前想象中的Html表達內容，css來表達外觀。而且CSS的存在，能夠表達更加精確更加豐富的內容，而且比用table這樣的表格排版更加簡潔明了。
14、XML作為Html的源頭
我把HTML表達網頁的內容這個想法給放棄了之後，很自然的想法是把XML作為Html的數據來源。但是這並不是很常見的做法。更多的做法是，利用數據庫，利用文件然後用網絡腳本進行提取，然後可能還要通過一道模板，直接產生HTML。其中並沒有XML的位置，那麼到底在產生Html的過程中需不需要XML呢？
現在問題已經很明白了，HTML完全作為一種表現語言。焦點是對於HTML從何而來這個問題。務實的態度是尊重現有的解決方案，而且它們可以做得很好。這裡只是對於XML能夠在產生Html的過程中的什麼階段進行參與工作，進行一些個人的看法的探討。
15、XML直接產生Html
這個可能是很多人頭腦中首先想到的辦法。利用XSLT，把XML轉換成Html。而且關於這個，我將在文章最後，給一個我個人的全面的想法。
我覺得利用XML產生Html，主要是用在小型的純發布的場合（比如個人主頁），因為對於XML文件的更新和刪除這些，並不是很完善。而且即使是使用XML數據庫，也不能勝任大型的場合。而XML更多的是作為中間數據
16、有數據庫產生XML然後產生Html
這可能是一個很好的方案。只是在現在看來有一些多余。因為網絡腳本從數據庫中提取了內容之後，直接就產生HTML了，或者調用一個模板也把HTML產生了。如果其中在多一個產生XML的過程，還需要再編寫XSLT來產生Html，讓人覺得沒有這個必要。
17、XML與數據庫
很自然的，就延伸出了一個討論就是"XML與數據庫，用哪一個？"。其實這個問題之所以成為，我認為是XML的發展不成熟。XML有其結構和功能上的優越性，但是同樣帶來了很大的復雜度。對於XML進行查詢，就比對於結構簡單的數據庫查詢復雜變數大很多。同樣，XML的表現力也要強很多。另外還與XML的兩個用法有關，XML一方面可以用作以數據為中心，比如網站的客戶訂單。這和關系型的數據庫的特點是一致的，每個table的項是固定的，數據都是類似重復的。而XML同時還能用作文檔為中心的，比如你寫一篇文章時，用XML對文章進行標記。這樣使得標記出現的位置，以及上下文就變得非常重要。
所以關於，在什麼場合下用XML，什麼場合下需要XML這種問題，很難有答案。至少有一點，隨著XML技術的完善和被越來越多的人掌握，XML會在其適合的場合越來越多的使用。
18、XML與網站
如果僅僅是泛泛而談XML與數據庫，我覺得是很難定論。但是如果把討論的范圍縮小到網站，我覺得還是很容易得出答案的。對於交互性的場合，比如論壇，數據經常要更新，XML就不適合。對於發布性的場合，比如文章系統，XML就是一個很好的選擇。當然還要考慮查詢是否方便。以及XML適合描述松散的信息，比如站長信息這樣的數據存放到數據庫中顯然是overkill，而放到xml中就比較合適。所以，我個人認為如果是個人主頁這樣性質的網站，使用XML是非常合適的。
19、在個人主頁中使用XML
個人主頁一般都是無法購買那種有網絡腳本支持的服務器的，更不用說數據庫了，這個是來自於現實環境的限制。個人主頁的數據一般比較松散凌亂，而且文檔比較多，比較適合XML來描述，這個是顯示的需求。
所以綜合了這兩點，對於一般個人主頁的站長來說，這樣的組合方案是很不錯的：
1、用XML來描述網站數據，用XSLT來做轉換
2、注冊一個免費的留言板
3、注冊一個免費的BLOG
這樣你就只需要一個Html空間，同時又可以實現內容與外觀分離，至少對我來說是一個夢想的實現。
20、最終實現指導
這個純粹是個人意見，而且技術門檻相對比較高一些，估計沒有人會采納。
第一步：
描述你的網站內容。如何描述完全是你的自由，而且是否使用DocBook這樣的東西來描述你的文章這樣的東西也是你的自由。描述應該分布在很多個xml文件之中，可以利用XInclude技術，也就是利用<xi:include href='...xml'/>這樣的標簽把所有的xml逐級串起來，最終是一個site.xml。找到了site.XML，就找到了你整個網站的內容。
你可以不用xinclude，而只是簡單的用一個元素記錄下文件位置，然後在XSLT中用document函數讀取也是可行的。
第二步：
描述你的網站的結構，也就是頁面的信息。這個我是用sitemap.xsl來做的。最終產生的就是一個sitemap.XML。裡面由類似這樣的元素組成：
<page name="article1" template="article.xsl" output="article1.Html" param="1"/>
這樣有兩個非常重要的作用，其一是能夠讓自動化的工具從產生的頁面信息中提取內容，自動調用xslt處理器把網站給編譯出來。其二是能夠讓頁面索引到其他頁面，比如你要在一篇文章的頁面中鏈接到所屬的分類的所有其他的文章，你就可以在sitemap.xml中提供出哪些頁面是干什麼的，比如所屬分類是什麼。然後具體page的xsl就可以在sitemap.XML中根據這些信息，然後找到頁面最終寫出超級鏈接。
第三步：
設計每個頁面的xslt。xslt的輸入有兩個，一個是site.xml，另外一個就是sitemap.xml。從site.xml得到內容，從sitemap.XML得到其他頁面的位置。
第四步：
利用你喜歡的腳本工具（設置是xslt+bat），自動化的完成整站的編譯工作。你還可以提供選項選擇編譯什麼頁面。
第五步：
你也可以自己編寫一個工具來實現新舊對比的FTP上傳工作。
OK，對於網頁設計的技術的我的思考就基本上告一段落了。
PS:很經典,每個學習WEB的人的經歷的濃縮!可惜我還是不能完全的理解!!~~
努力中.........