公司招了幾個剛畢業(yè)的學生，作為重構的新手讓我來帶。
　　首先感謝感謝黨、感謝國家、感謝公司給了我這樣的一個機會，對我工作的肯定和認可，讓我?guī)н@樣的一個重構團隊，同時我也明白任務的艱巨，但我一定會將工作做好，不負公司對我的期望。(哈哈，好像從小到大，老師都是教育我們要這樣先說的。)
　　在網(wǎng)站的發(fā)展史上，初期的網(wǎng)站建設根本不需要網(wǎng)頁重構這個職位，WEB1.0時代的網(wǎng)頁，只需要程序員，一堆堆的表格嵌套就完成，或者美工進行配合完成，先由美工負責設計好，再用一些自動化的軟件拉伸幾下，直接將設計好的圖就可以通過軟件輸出表格的布局了，根本不需要重構這個多余的職位。隨著 WEB2.0的到來和W3C的規(guī)范得到世人的認可，內(nèi)容和樣式的分離更方便進行開發(fā)和維護，傳統(tǒng)的表格布局和內(nèi)容混排的方式逐漸地被淘汰，美工已不能完全一手包辦越來越復雜的效果和高要求的頁面布局了。此因催生了一個新的職位——前端工程師。
　　鄙人剛好作為一名WEB2.0成長起來的前端工程師，雖然說做的項目不多，但樂于與人分享。雖然分享的也許只是一些很表面甚至有些過時的東西，但也只希望為大家提個醒，最好能起到拋磚引玉的作用。
　　一、前端工程師的職能和作用。
　　什么是前端工程師?有人這樣來表述：我們是工程師中的設計師，是設計師中的工程師。上班不干別的，就是玩，弄點效果，攢兩頁面，搞點創(chuàng)新。我們就是前端攻城師(工程師)。當然這個表述有點有點輕巧、調(diào)侃的味道，工作絕對不是玩那么簡單的，有時候會為一些效果的實現(xiàn)或優(yōu)化，弄得加班加點一起開發(fā)，但其實有兩一句表述是非常中肯的，那就是：我們是工程師中的設計師，是設計師中的工程師。這句話將前端工程師的角色的定位說得很準確。前端工程師，在網(wǎng)站開發(fā)的初期，以工程師的身份來指導網(wǎng)頁的設計，前端工程師明白程序的輸出的方法，指導設計師在設計的過程中避免一些不能輸出的數(shù)據(jù)排版，指出哪一些陰影、透明、圓角的使用不能大范圍的使用等等;在進行頁面的重構的過程中，又將以一個設計師的身份將設置頁面轉(zhuǎn)化為靜態(tài)頁面，需要用代碼對設計頁面進行最初的還原，實現(xiàn)好相應的前臺的效果，排列好相應讓后臺開發(fā)的工程師輸出數(shù)據(jù)的地方，以適應后臺數(shù)據(jù)的輸出并保持頁面的不變形、不走位，在有數(shù)據(jù)輸出正常的情況下，配合程序去修改樣式，以盡量達到和設計的效果基本一致。所以在這個頁面設計和到程序的現(xiàn)在過程中，需要前端工程師起到一個橋梁的作用。
　　前端開發(fā)是一項很特殊的工作，前端工程師的工作說得輕松，看似輕巧，但做起來絕對不是那么的簡單。在開發(fā)過程中涵蓋的東西非常寬廣，既要從技術的角度來思考界面的實現(xiàn)，規(guī)避技術的死角，又要從用戶的角度來思考，怎樣才能更好地接受技術呈現(xiàn)的枯燥的數(shù)據(jù)，更好的呈現(xiàn)信息。簡單地說，它的主要職能就將網(wǎng)站的數(shù)據(jù)和用戶的接受更好地結合在一起，為用戶呈現(xiàn)一個友好的數(shù)據(jù)界面。
　　二、前端工程師的發(fā)展前景如何
　　前端工程師是是一個很新的職業(yè)，在國內(nèi)乃至國際上真正開始受到重視的時間不超過5年?；ヂ?lián)網(wǎng)的發(fā)展速度迅猛，網(wǎng)頁由WEB1.0到WEB2.0，再到新生的HTML5、CSS3，到現(xiàn)在手機、3G網(wǎng)絡等新科技的興起，網(wǎng)頁也由最原先的圖文為主，到現(xiàn)在各種各樣的基于哀前端技術實現(xiàn)的應用、交互和富媒體的呈現(xiàn)，更多的信息、更豐富的內(nèi)容、更友好的體驗，已經(jīng)成為網(wǎng)站前端開發(fā)的要求，網(wǎng)站的前端開發(fā)發(fā)生了翻天可覆地的變化。
　　網(wǎng)站的開發(fā)對前端的需要越來越重要，但個新和職業(yè)在業(yè)務還是很缺，所以高質(zhì)量的前端開發(fā)工程師將會是后五年內(nèi)一個非常熱門的職業(yè)，發(fā)展的前景非?？捎^。
　　三、前端工程師需要掌握的技能
　　作為一個前端工程師，需要掌握的技能還真的不少。
　　最基本的三個技能：HTML、CSS、JavaScript
　　這個是前端開發(fā)中最基本也是最必須的三個技能。前端的開發(fā)中，在頁面的布局時， HTML將元素進行定義，CSS對展示的元素進行定位，再通過JavaScript實現(xiàn)相應的效果和交互。雖然表面看起來這些很簡單，但這里面需要掌握的東西絕對不會少。在進行開發(fā)前，需要對這些概念弄清楚、弄明白，這樣在開發(fā)的過程中才會得心應手。
　　HTML：
　　指的是超文本標記語言 (Hyper Text Markup Language)，這個也是我們網(wǎng)頁最常用普通的語言了，經(jīng)歷了多個版本的發(fā)展，現(xiàn)在已經(jīng)發(fā)展到4.01版了，得力于W3C建立的標準和規(guī)范，現(xiàn)在已普遍升級到了 XHTML，XHTML 指可擴展超文本標簽語言(EXtensible HyperText Markup Language)， XHTML 于2000年的1月26日成為 W3C 標準，是更嚴格更純凈的 HTML 代碼，XHTML 的目標是取代 HTML。XHTML 與 HTML 4.01 幾乎是相同的，XHTML 是作為一種 XML 應用被重新定義的 HTML，是一個 W3C 標準。W3C 將 XHTML 定義為最新的HTML版本。所有新的瀏覽器都支持 XHTML。
　　另外，W3C 與 WHATWG 合作創(chuàng)建一個新版本的 HTML，就是HTML5。HTML5 將成為 HTML、XHTML 以及 HTML DOM 的新標準，為HTML世界注入更多驚喜，盡管HTML5 仍處于完善之中，然而，大部分現(xiàn)代瀏覽器已經(jīng)具備了某些 HTML5 支持，顯示出來的生機和活力已是那樣的激奮人心，特別是前端的工作中，那些針對瀏覽器兼容的問題將能得到很好的解決，更多的效果和應用也能更方便的實現(xiàn)。
　　前端工程師，也必然要與時俱進，緊跟業(yè)界時代發(fā)展的前沿，不然永遠只停留在舊的技術上，只會被無情的淘汰。
　　其實HTML的元素也就不過幾十個，常用的元素更少，所以掌握起來的話應該不困難。但就是這些看似簡單的元素，很多新手在剛開始的時候就不注意規(guī)范，養(yǎng)成一些不好的習慣。
　　1、不要忽略一些細節(jié)
　　隨便打開一個個網(wǎng)站，隨手點到了163的首頁，163算是一個比較規(guī)范和專業(yè)的門戶網(wǎng)站了，已經(jīng)用上了HTML5的一些元素了，具體可以看到源文件。

　　在頭部的焦點廣告圖那里，用小BUG右鍵查看一下元素，看到這樣的一個圖像標簽img代碼：

　　img必備和可選的參數(shù)都有寫了上了，但是必備參數(shù)里的一個值alt沒寫(其實一些大型的專業(yè)門戶網(wǎng)站其實也是有存在一些小問題的，只要我們細心一點就能發(fā)現(xiàn))。雖然這樣alt不寫，在頁面中也不會有任何的問題，因為這個alt屬性也只是在圖像丟失、禁用或加載不到的情況下才顯示，但是如果一些其他特定的設備訪問或一些其他條件下圖片不顯示的情況下，那這里就是一塊大紅XX和一大塊白塊，多影響用戶體驗。

　　雖然只是一個小小的alt屬性，但是有時候是細節(jié)決定決定成敗，用與不用，表面上看不出有什么問題，但是在某些特定的條件產(chǎn)生的作用是無法估計的，也就是從這些小小的細節(jié)就可以看出一個前端工程師的水平如何。
　　一些前端的新同學甚至什么也不填，放一張無任意命名意義的圖上去就算了事，養(yǎng)成這樣的習慣是非常不好的。

　　2、規(guī)范語義使用標簽
　　很多同學說是學習div+css，其實這個說法是存在誤區(qū)的，甚至是錯誤的。一個規(guī)范標準的頁面是合理地使用標簽，使其更加語義化，如果只是靠一堆堆的div通過層層的嵌套來布局完成的話，那么，除了div和a標簽這兩個標簽外，所有的HTML元素都沒有存在的必要了。

　　上面是一個前來應聘的朋友發(fā)給我看的一個頁面布局作品(點擊進行查看)，這個同學還算是工作了一定的時間的，據(jù)他介紹之前是在游戲公司工作的，但不知是不是當時所在的公司是不是他負責 前端這塊的，不做評論。
　　這個朋友的頁面在瀏覽器查看沒有什么大問題，瀏覽罵的兼容性還可以說是沒有太大問題的，雖然從頁面的效果上看起來沒有什么問題，用小bug一看，可以看到他寫的這個代碼好像還蠻整齊的，所有的東西都是一層層的div，包裹得很仔細，類的命名也很有規(guī)律，但仔細一看，這個導航做的很有問題。查看一下源文件，發(fā)現(xiàn)不僅僅只是導航的問題了，整個頁面都有問題，所有的body下出現(xiàn)過的HTML標簽加起來總共只有七個，分別是：div、a、strong、 font、input、br、img。先不說他寫行內(nèi)樣式、align在HTML4.01中已經(jīng)丟棄的屬性這些很低級錯誤的問題，一個很大的問題就是，語義的使用極不規(guī)范，使用層層的div來包裹定位。
　　例如這個導航可以用一個無序列表ul來就可以完成了，這樣簡潔明了，不需要這么多div和巨量的樣式來進行控制，最重要的是語義化也比較清晰了。

　　網(wǎng)頁布局就像是一篇文章那樣，有標題、有段落、有加強、有突出，HTML提供了這么多的元素給我們使用，就是要求我們要按照其語義來使用，該用標題的時候用標題(h)，該用段落的時候用段落(p)，該重點強調(diào)的時候用強調(diào)的強調(diào)(em、strong),而不是都不管三七二十一，千篇一律的先用div 來包裹再來進行控制。我們使用了這些相應語義的HTML元素，同樣可以使用css來進行控制的，可以達到任何我們想要的布局效果的。css的魅力就在于此。

　　研究表明， 語義化的標簽，越少的嵌套，對瀏覽器的解析就越快，顯示的速度就越快，當然對不同用戶群的用戶體驗也就越好!特別是對于一些特殊群體和閱讀設備，如盲人，使用的是閱讀HTML的機器，對于一塊塊的div，就不知道哪里是標題哪里是正文了，只能閱讀到的是這里有一整塊的內(nèi)容。如果使用的是語義化的標簽就不一樣了，即使看不到屏幕，但也知道哪里是標題哪里是標題下相應的正文。所以，我們有css這個這么神奇的東西幫助我們網(wǎng)頁布局的時候，語義化的使用HTML 標簽，用最少的嵌套和代碼實現(xiàn)同樣的效果，就是我們前端工程師所追求的。
　　再次回到前面div+css布局的一些誤區(qū)，什么是div?它的英文名是division，意思是分開、分割、分塊的意思。也就是說div在網(wǎng)頁中是用來進行分塊布局或是在沒有更適合的HTML元素的情況下用來配合分塊布局的，如果胡亂的濫用div，那么就會犯上"div控"了。剛入門不久的新同學最容易會犯這種思想的。
　　CSS：
　　CSS (Cascading Style Sheets)指的是層疊樣式表，現(xiàn)在普遍在用的版本是css2.1 ，雖然已經(jīng)發(fā)布了3.0的版本，且有一些個人的博客和站點已經(jīng)使用HTML5+CSS3了，但受目前國內(nèi)的主流瀏覽器IE6的影響，更多的人還是在使用 2.1的版本，在這個的基本上有選擇性的使用少量的不影響兼容的css3某些功能，css3的普及還需時日。不管如何，css3的出現(xiàn)讓我們眼前一亮，增加了很多新的屬性，如圓角、陰影、漸變、動畫、流媒體等等的效果，讓頁面實現(xiàn)的效果更加方便和容易。
　　現(xiàn)在要和大家分享的并不是css3哪些激動人心的屬性如何使用和實現(xiàn)，因為這些當我們學習到了一定階段的時候都會去學習到css3這個將來必將成為王者的使用，現(xiàn)在與大家分享一些與版本無關的東西，讓大家在學習的過程中少走一些彎路。
　　1、 Reset
　　關于重置也有太多的東西要說了，YUI、Eric Meyer等都有各自不同的方法，甚至有些人是不用重置的，不管怎樣，只要遵循一個原則：適合自己的就好。所以不對這方面過多的強求，也不作過多的討論。因為要討論的話幾大篇幅也討論不完。當然我自己有一個自己用的reset的地方，究竟好與不好，大家有空的時候可以研究，最好能把研究的結果與我分享，我也很愿意聽。這個是我的Reset的文件，大家可以點擊下載(aqy106_lab.css)
　　2、 樣式書寫要注意的事項
　　看過《Efficient, maintainable CSS》的譯文《如何書寫高效、可維護、組件化的CSS》，里面講到一些樣式的書寫要注意的事項。還是看一看這個同樣是一個新同學寫的樣式，看上去很整齊，命名也很有次序，但是仔細一看，問題還是很多的，先不說命名，因為這個得用另外的一個篇幅去說了。

　　如果作為一般的小站這樣寫，樣式的也許只是多幾個K的大小的問題，在性能上影響并不大，但在大型的網(wǎng)站中，幾個K的大小就不容忽視了。

　　基于前人的總結，個人認為高效的css書寫應該要注意：
　　1)、精簡屬性寫法，提高可觀賞性

　　很多屬性是有精簡的寫法的，如padding、margin、background等等，這些寫法雖然可拆可合，但我們習慣了精簡的寫法后，會讓css更加整潔、明了，看起來更加賞心悅目，感覺寫css就是一個雕刻一件藝術作品。
　　2)、使用多重選擇器，提高可重用性

　　多重選擇器的寫法相信很多人都會使用，但是多重選擇器的使用與進行二次編輯或多次編輯的時候會有一個矛盾，多次的修改，有可能需要重新定義的樣式不同，這時候又需要重新的將原先的選擇器進行分享出來單獨定義，這不能不說是一件痛苦的事情，所以在使用多重選擇器的時候，最好能將固定的版塊進行使用多重選擇器，這樣大大降低你日后維護、編輯的成本。當然，這是需要你的時間和經(jīng)驗才能積累起來的。
　　3)、減少層級及繼承的寫法，一般不輕易用id

　　相信很多人都會考慮到重用這一高效的寫法，所以越少的層級、越少的繼承就為重用這一方法的實現(xiàn)提供了可能。也許有人會說，那我可以采用上面的"使用多重選擇器"來進行提高css的可重用性啊。其實這里面還有另外一個原因，就是更少的層級，渲染所使用的時間更少。css的渲染與JavaScript的方式完全不一樣，JavaScript的篩選直接使用id，能夠精準的定位到相應的dom，但是css的層級多的話反而會影響到性能，但具體沒做相應的測試。此處也許不嚴謹，請大家賜教，哪位大俠有空來測試一下，給一些相應的數(shù)據(jù)會有更好的說服力。但基于重用的原則，個人還是建議用最直接、有效的簡短的命名，也同樣就是這樣的一個原則，雖然id的唯一性解決了沖突了問題，但違反了重用性的原則的同時也加大了維護和的成本，如非必要，盡量不用id。
　　4)、命名面向?qū)傩院兔嫦驅(qū)ο蠼Y合
　　其實命名這個方面有很長的一個篇幅可以說的，因命名的方法和各個人的習慣也不樣，有人喜歡用駝峰式，有人喜歡下杠線，有人喜歡縮寫，也有人喜歡全寫，個人認為這個主觀色彩太重了，不予作過多的展開，不管哪一種，都是沒有問題的。
　　和大家分享的是另外一個問題，是樣式的命名是面向?qū)傩赃€是面向?qū)ο竽?相信這個也會困擾著一些同學?，F(xiàn)在就和大家分享一些我的心得。在分享我的觀點之前，先跟大家解釋一下什么是面向?qū)傩浴⑹裁词敲嫦驅(qū)ο?。面向?qū)傩跃褪敲嫦騝ss的屬性來進行命名，面向?qū)ο缶褪敲嫦蛞貥嫷捻撁娴哪K這個對象來進行命名。如下圖：

　　4.1面向?qū)傩悦?/p>

　　4.2面向?qū)ο竺?br />　　關于這個問題，有人覺得面向?qū)傩院?，因為可以最大限度的利用好css的重用性;也有人認為面向?qū)ο蠛茫驗槊嫦驅(qū)ο罂梢宰尯笃诘木S護更方便直接。既然各自都有好處，那我們可不可以將兩者結合起來呢?答案是肯定的，而我個人也是這樣做的。
　　對于一些固定的、常用的、重用性非常高的css，可以將其按面向?qū)傩詠磉M行命名，前面前的"面向?qū)傩悦?quot;的這個圖這樣，也可以說是一個小小的框架或是作為一個底層來方便自己的開發(fā)，放到哪里都是可以使用，具體可以見我整理的自已用的面向?qū)傩缘腸ss(點擊下載aqy106_lib.css)。另外對于于具體的版塊就應該使用面向?qū)ο?，針對版塊的對象來進行命名，這樣也讓后期維護或接手的人來編輯也不會困難。163采用的也是采用面向?qū)傩院兔嫦驅(qū)ο蠼Y合的方法來進行命名的。

　　作為一名前端開發(fā)的工程師，應該要有一利節(jié)流的思想，把css的書寫當作一門藝術來學習、來追求。書寫出一個高效、可維護的樣式往往是通向大師之路的必走之路。
　　樣式不僅僅是寫給自己看的，更要給團隊開發(fā)或后來接手的人看的，如果能做到簡潔、高效、重用性、可讀性強，相信，你離大師的級別也不遠了。
　　3、 CSS Sprite(圖片精靈、背景定位技術)
　　現(xiàn)在的網(wǎng)頁，各種各樣的媒體、圖標、背景都是多得眼花繚亂的，特別是背景圖片、圖標是我們網(wǎng)頁中使用最多的，按照以前的使用的話，插入一個個的小圖標或圖片用來控制來進行修飾，這些不和內(nèi)容相關的圖標圖片也一并混排在內(nèi)容中了，且頁面中一大堆無關的圖標圖片，還不方便管理。并且還有一個很大的弊病，一個圖片在頁面中是一個http的請求，頁面中存在n個的這樣的小圖標的話，對服務器的請求也就有N個，也許對于一些小站來說沒什么影響，但對于一個大型網(wǎng)站來說的話，這個數(shù)字可就不得了，這時的服務器并發(fā)請求就會多上N乘以用戶的個數(shù)，這樣無疑加重了服務器的負擔。

　　而解決這個問題的最好辦法就是CSS Sprite。
　　將所有的圖片整合到一張大圖上，通過css來進行定位。首先能將內(nèi)容和修飾的元素進行了分離;其次能減少頁面請求的個數(shù)，那么減輕了服務器的負擔;再次，能夠提高頁面加載的速度，加快頁面載入速度，提升用戶體驗。
　　另外，將圖標圖片作為背景來進行加載，都是在文檔的主要內(nèi)容進行加載完畢，再加載樣式時才進行請求的(細心的大家也許也發(fā)現(xiàn)，網(wǎng)絡不好的時候，頁面加載進來的是亂七八糟的，待一會樣式加載進來后，頁面馬上正常了，其實這個就體現(xiàn)到了文檔加載的先后順序，如果不相信的話，可以用小bug或相應的工具查看一下是不是這樣的加載順序)。

當然，事物都是具有兩面性的，將小圖標小圖片整合到一張圖片上，雖說有百利，但仍有一害的，就是當需要更換圖標或調(diào)整的時候，必須要在這張圖片進行處理和定位，需要在FireWork等這些圖像處理軟件中定位好坐標再去寫相應的CSS，會增加一定的工作量，如果身邊沒有這些工具，處理起來還是會有些麻煩的。但總的來說，圖片整合，利大于弊，我們?yōu)楹尾挥媚兀?br />1、 兼容性
2、 以Trident為內(nèi)核的IE、以Gecko為內(nèi)核的FireFox、以Presto為內(nèi)核的Opera、以Webkit為內(nèi)核的google chrome和Safari等四大內(nèi)核的瀏覽器四分天下。
兼容性的問題相信是很多前端工程師肯定會遇到且最頭痛的一個問題，且不說目前市面在有這么多的瀏覽器，就僅僅單一的IE系列家族的問題也夠多的了，特別是IE6，雖然微軟宣布了IE6的死亡，但國內(nèi)的機器仍以IE6為主流，IE6在國內(nèi)的法消亡還需時日，作為前端開發(fā)沒法規(guī)避的情況下，暫時也只能折衷的進行兼容。不過雖然繁多復雜，但我們可以化繁為簡，重點問題重點處理，基本上IE6的問題解決了，也就解決最大的問題了。
當然，這個IE6的問題太多了，需要用另外的篇幅去進行說明了，這里就不再跟大家再作深入的研究了，給大家提個醒，讓我們一些新同學在成長過程中能夠有目的地去學習、發(fā)現(xiàn)和處理問題就OK了。
3、 圖片的優(yōu)化
雖然現(xiàn)在的富媒體越來越多了，網(wǎng)頁展現(xiàn)的數(shù)據(jù)從單一的圖文向音頻、視頻、動畫等類型擴展，但受限于網(wǎng)絡傳送帶寬、速率等影響，圖片仍以最高的可壓縮比、傳送速度快、展現(xiàn)效果好等優(yōu)點作為一個主角在網(wǎng)頁呈現(xiàn)和展示方面活躍著。目前網(wǎng)頁主流的格式現(xiàn)在常用的也就不外乎幾種：png、gif、jpg，其他一些在網(wǎng)頁中不常用的格式暫不在本次的討論之列。
3.1圖片格式知多少
相信png、jpg、gif這些格式大家都能大概的了解和清楚一些使用，這里就不再細說，這里說一些使用中注意的事項或是大家不夠深入了解的東西。
png：png有多個不同的位數(shù)的格式：png8、png24、png32。前端的新同學們常常遇到的就是png在IE6中不透明，其實IE6是支持PNG透明的，不過只支持png8的透明而已，具體可以看我的頁面中圖標，就是用了png8的透明，但是png8下不支持半透明，所以頂部的這個有背景色的時候用了png32配合JS處理了一下透明效果，不然有白白的邊在 IE6里太難看了。png8和gif都支持全透明和256色，所以在正常情況下兩者是可以互換的，兩者輸出的大小也差不多，甚至png8比gif更有優(yōu)勢，但png8不能像gif那樣做成動畫。
而png24和png32也有一些不同。png24在png8的基礎上增加了顏色的支持數(shù)，但是沒有透明信息，png32在png24的基礎上增加了透明的信息。Firework和Photoshop雖然同為Adobe公司的產(chǎn)品，但是輸出的時候也是有些不太一致的。Firework能夠正常的輸出各種規(guī)格的png，但Photoshop不支持8位png+alpha透明的格式，而且Photoshop中也沒有32位png選項，其中的png24+ 透明實際上就是 png32（不信你可以嘗試用Photoshop輸出一個png24+透明的png再到Firework中看看就知道了），如果要IE6支持png32的透明，就只能用別的方法了，而我采用了js的方法，用法可見《IE6下PNG圖像透明完美解決方案》（其實標題應該改成"IE6下PNG32圖像透明完美解決方案"）。

gif：gif和png8一樣，都是只支持256色，模式都是索引顏色，但gif比png一個較大的優(yōu)勢是可以將圖片做成動畫，而png8不能（現(xiàn)在最新版的png標準是支持一個文件內(nèi)存放多個圖像的，也就是說同樣可以做動畫的）。
現(xiàn)在還有一些更非常規(guī)的圖片的用法，大家可以看到google的404頁面（點擊打開GOOGLE 的 404頁面），將圖片進行base64編碼再放到css中（當然IE6、7是無法正常解析的，嘿嘿）。

這種data: URI的格式能把base64（或其他數(shù)據(jù)）可以內(nèi)嵌在image標簽的屬性當中（或者CSS中或JavaScript中），通過對圖片進行base64 編碼，可以實現(xiàn)將圖片直接嵌入代碼中的目的，如此一來，可以減少HTTP請求，這對于提升web性能很有好處。對于較小的圖片，采用這樣處理是非常實用的，但是IE６、７不能支持這種方法，因此可以在IE6、７中采用傳統(tǒng)的方法，而在其他瀏覽器中使用這樣的方法來進行全面的兼容。
這種做法有利有弊，好處是可以減少HTTP請求，不好的地方是圖像的大小會增加1/3。因此，這種內(nèi)嵌的方法適合對小的圖形、小圖標等進行處理，從而減少瀏覽器打開的連接數(shù)，但對大的照片、圖片等則不應該使用base64編碼了，以免影響圖像下載的時間。
但這種圖像的處理也需要另外的軟件，所以不熟悉的情況下操作起來也有一定的困難，這里有一個在線版的轉(zhuǎn)換工具，有興趣的大家可以試試，嘗嘗鮮：點擊打開
當然這些都是更深一點的應用了，我也在學習當中，無法再作更深入的論述了，大家可以自行進行擴展。當然，我也樂于分享你們的觀點。
擴展閱讀：《Data URI scheme》
更多的圖片的格式可以查看一篇老外的文章，也有人進行了介紹：
《Tips for choosing a cache image format 》
《The difference between PNG24 and PNG32》
外文不太好的也可以看這里，有人進行了相應的概括：
淘寶UED： 《圖片格式與設計那點事兒》
尹延超：《 PNG詳解》
6.2如何輸出合適的圖片
說了這么多的圖片格式相關的知識，現(xiàn)在要實際操作來說明一下我們怎樣輸出一個適合我們的圖片了。
其實淘寶UED： 《圖片格式與設計那點事兒》這里也說明得夠詳細了，這里就不重復里面的一些方法了。我們最常用的圖像處理軟件莫過于Firework和 Photoshop，所以我們也以這兩個軟件就重點。雖然兩個軟件現(xiàn)在是同出一家，同屬一個Adobe Master套裝，但兩者的算法還是有一定的差別的。所以在做圖片處理的時候有時候可以在這兩個軟件中分別進行輸出對比來決定最后圖片的使用。

注：本文使用的是Adobe Master CS4開發(fā)套裝的，其他的版本沒測，已知的是Firework8中圖片輸出的算法也沒有Firework CS4的好，具體可以親測。
這里不再進行深入的論述，大家清楚了上面的格式的差別和軟件的問題后，在具體的工作中通過不停的比較就能得出上面這些結論。
JavaScript：
因本人也是JS菜鳥一個，也正在努力學習的階段，沒法跟大家深入的講JavaScript的一些核心代碼分析什么的，所以講一些無關緊要的所謂的理論問題。
頁面除了數(shù)據(jù)層的html、展示層的css，還有一個動畫和交互層的腳本，那就是JavaScript。JavaScript可以說是目前Web開發(fā)中一個非常流行的語言了，如果一個前端工程師能夠精通此語言，就單一項語言也能成就一份非常不錯的工作。
相信大家對之前google里的那個用JavaScript做的紀念瑪莎·葛蘭姆的動畫還不會陌生，點擊此處觀看，這個用JavaScript配合圖像定位做成的動畫，展示了JavaScript的強大功能。
現(xiàn)在Prototype、JQuery、Mootools、Dojo、Extjs等的框架，各種各樣的基于js框架開發(fā)的插件方便我們的開發(fā)，大大的熱縮短了我們學習的周期，簡化了前端的開發(fā)，加快了開發(fā)速度，同時避免各類瀏覽器的兼容性問題。目前前端開發(fā)者使用JS框架是種很普遍的現(xiàn)象，但是我們的開發(fā)應該按需要