一、css爲什麼放在在head中而不是body裏面或者其他地方？
都說放body裏面是不符合標準，其實最主要的原因不是如此，因爲我們在實際情況中會有body中出現css鏈的存在（雖然這樣很二，但是卻不得不承認偶爾這樣二的事還是會發生），事實也證明在瀏覽器的寬大下這樣的方式也可以正常處理，那麼言歸正傳爲什麼要盡力把css鏈放到head頭部呢？瀏覽器頁面渲染方式是在所有的stylesheets（也就是前面的css鏈）加載完成之後，纔會開始渲染整個頁面，在此之前，瀏覽器不會渲染頁面裏的任何內容，頁面會一直呈現空白（這也是一些網站前幾秒空白的主要原因之一）。這也是爲什麼要把 stylesheet 放在頭部的原因。如果放在 HTML 頁面底部，頁面渲染就不僅僅是在等待 stylesheet 的加載，還要等待 html 內容加載完成，這樣一來，用戶看到頁面的時間會更晚。順帶說下現在很早不用@import也是因爲，它的處理方式是將css <link> 標籤放在頁面的底部加載。
在我們實際的運用中，相對有經驗點的前端在img的外部都會有相對的包裹也就是parent box來限制圖片的寬高，避免二B的產品傳錯圖片搞亂整個頁面佈局，處理這個問題的方法每個前端可能都不同有的是定義父級的寬高然後在進行overflow:hidden；而有的可能是直接繼承或者給圖片類來設置死圖片的高寬，那這個時候問題來了，我們這裏已經對圖片做了諸多針對二B的保護措施，那圖片的這個2個屬性是否多餘了？NO，在這裏我們首先必須肯定前輩們設置的每個屬性標籤都是有它存在的價值和經過諸多考慮的（當然隨着互聯網的發展，廢去的諸多標籤屬性，並不是前輩考慮不周而且互聯網進步實在太快了），在css 的渲染過程中，它是逐一渲染堆疊的（和疊沙樓一樣先渲染完前面的才繼續往下渲染），而在這個堆疊渲染的過程中當已渲染元素的寬高等layout改變時會重新回頭開始渲染（這也就是所謂的迴流），而在頁面加載過程中從html的讀入到css的渲染，圖片加載總是會慢人一步（很多情況下css讀寫完畢後圖片可能還並未加載出來），因此指定的所有圖像的寬度和高度可以通過消除不必要的迴流與重繪需要更快的渲染，當然對於父級已經固定寬度的行爲這裏img的屬性也就相對沒有那麼重要了。
說到圖片這裏順帶說下，不要對圖片進行縮放也就是圖片的實際大小大於他的顯示必要，比如一個800*600的圖片，而我們在頁面上只顯示的是400*300的大小，那麼這便是一種服務器資源的浪費（當然這個其實完全要看後期產品維護了），同時alt這個屬性千萬別偷懶，或許這個屬性在正常情況下基本沒用處而且浪費字節，但是對於灰色世界的盲人來說圖片他們是看不到的，而alt才能告訴他們這是一張什麼樣的圖。
三、css選擇符越詳細越好嗎？爲什麼？
其實這個問題，我想很多前端都不會犯，但是對於新人或者涉足不深的人來說偶爾不經意間還是會寫出來，在說這個前，首先我們應該知道css的查找方式和js的不同，總所周知js查找元素是從上向下的查找，也就是先查找到父級，接着在是子級，而css則相反，它的屬性選者符是從後向前查找的，比如.class .a則是先會遍歷整個dom樹查到類名爲a的元素接着在繼續向上查在這個元素的父級上有沒有一個類名爲class的元素，沒有的話這繼續查找直到查找完所有的元素爲止（http://www.zhihu.com/question/20185756/answer/14263713），因此對於屬性選擇符則是越簡略越好（當然基於模塊化卻不能完全執行這個準則），因爲這樣會加快查找速度（無需根據上級類去一一匹配），同時也會方便你的維護和修改，除了性能還能方便維護和修改，因爲對於選擇符優先級，越詳細則寫的越深（即層次越多）那當下個元素需重用覆蓋的時候必須要寫比前者更高的優先級層次，那麼這樣的模塊越多你的代碼也就疊加的越高，而且對於以後的模塊遷移調整起來更加是場災難；例如要定義div .a 下的 ul 中的所以li的字符大小 .a ul li{font-size:12px;}這樣中的ul是遠遠多餘的因爲li本身就是不可能單獨存活的，當然如果你a中有ol的話那我更加建議給ol和ul分佈加上類去單獨定義；
四、expression爲什麼不建議用？以及＊通配符爲什麼也不建議用？
對於萬惡的ie6中最小寬高不得不說是比較讓人鬱悶的東西之一，而那個時候expression閃閃發光的跳了出來，後來漸漸隱沒當然還是有那麼一小撮懷舊的偶爾會用用，很多人只知道用它性能不好也就不用了，但是卻不知道爲什麼性能不好，其實相對的來說在css中能直接運用expression這樣的js表達式來處理一些簡單的事情還是比較前衛和值得開心的（當然這樣和分離有點背道而馳了），但是不幸的是這個屬性僅僅是ie特有的，而且它運用起來性能存在嚴重的問題，它的問題就在於它的計算頻率要比我們想象的多，不僅僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動鼠標時都會要重新計算一次，大家可以做個測試在這個表達式中增加一個計數器來跟蹤表達式的計算頻率，最後在頁面中隨便移動鼠標，可以看到它輕鬆達到10000次以上的計算量，想想這鬼東西揹着我們在後面吃了我們多少內存。所以真愛用戶遠離expression，其實針對ie6對於寬高的處理特性來說換個方向，它是遠遠都足夠表現最小寬高的（ie6對於寬高處理方式是元素大於父級時會撐大容器而不是溢出），當然最大寬高的解決方案相信親都不用我說了這裏也就節約下力氣。
然後我們說說通配符，我記得在08年那段時間通配符真是個神器，爲我們可是省了不少力氣，大家那個時候都愛用它，甚至很多書本也會專門的劃出一部分來講它，但如今相信很多人都不用說已經開始擯棄它了，大家都有了一套自己的reset小庫或者小段落，但是爲什麼這麼省事的東西現在大家卻想法不用呢？因爲對於＊它會遍歷所有的dom去一一的執行我們定義的樣式，那這可真不是個小工程，就像大家以前最常用的＊｛margin：0；padding：0｝這個會設置所有的元素內邊矩和外邊距，但是在實際情況中並不是所有的元素都需要這樣做，那它帶來的就是負擔了，同時也儘量要避免類名下直接定義通配符，這樣做瀏覽器會匹配文檔中所有的元素後分別向上逐級匹配這個類的元素，直到文檔的根節點，其匹配開銷非常大，通常比開銷最小的ID選擇器高出1~3個數量級，所以也要避免使用關鍵選擇器是通配選擇器的規則。（關於css選擇符及性能更詳細可以看看https://developers.google.com/speed/docs/best-practices/rendering?hl=zh-TW）
五、css合併圖片是越多越好嗎？
現在對於超鏈過多請求影響網頁加載是大家總所周知的一件事，大家都會習慣圖片合併成一張，來獲取更好的性能，在這樣做的同時也付出了一定的代價，圖片的體積更大了，更有甚者一張圖高達200多K，這樣圖片帶來的效果是否會真的更加好？我們都知道這樣合併之所以好，是因爲它減少了從服務器多餘的請求所消耗的等待時間，比如10張4k的圖片那就要請求10次，最後的總大小也就是40k，但是圖片合併到一張後只需請求一次，而且合併後的圖片可能並不會大於這40k（合併的圖片要比分離的圖片的總和要小，因爲它降低了圖片自身的開銷如顏色表、格式信息等），這其餘的九次請求也就是節約來的性能，但是事情也是相對的，請求次數是少了，但是服務器承載的負擔卻會比開始大大增加同時以太網最大傳輸單元MTU爲1500字節而當我面合併的圖片過大時會最大限度地加大動態和靜態資源的有效載荷大小增加網絡延遲。對於一個大型的門戶網站來說一張200K的圖片每天幾十萬幾百萬的請求對服務器的承載負擔是相當重的，在css和頁面渲染完畢後背景圖片會姍姍來遲所帶來的交互也是很不好的，同時對於後期的按鈕等修改帶來的維護成本也很高，所以這裏建議合理運用。（更詳細的可以可以看看https://developers.google.com/speed/docs/best-practices/payload?hl=zh-TW）
六、table真的那麼可惡不要運用嗎？還有html怎麼去優雅合理運用？
現在很多面試都會問是div+css嗎？不用表格的吧？（當然前幾年比較多，現在都改爲會css3和html5，我擦）其實這樣問的多數都是你未來的lead，對於表格其實我想說它真的很冤枉，它自身對於數據的展示是無可取代的，雖然在強大的css下ul、ol甚至div都可以完美的來達到這個效果，但是我想說現在我們做的事和多年前去用表格佈局有什麼不同呢？所以施主放過table吧， table它的存在對於數據的展示本身就是它重要的使命否則爲啥沒用在廢除b這樣的標籤的時候幹掉它呢？當然table確實也是有它的侷限性，總之合理應用（數據展示最終也要看標準和展示形式）。
對於html的合理應用，其實最重要的是理解標籤的語義，在這裏我推薦個文章就不在囉嗦了。http://sofish.de/1688
如果有更多的爲什麼不清楚的可以留下來大家共同討論
