一、css為什么放在在head中而不是body里面或者其他地方？
都說放body里面是不符合標準，其實最主要的原因不是如此，因為我們在實際情況中會有body中出現(xiàn)css鏈的存在（雖然這樣很二，但是卻不得不承認偶爾這樣二的事還是會發(fā)生），事實也證明在瀏覽器的寬大下這樣的方式也可以正常處理，那么言歸正傳為什么要盡力把css鏈放到head頭部呢？瀏覽器頁面渲染方式是在所有的stylesheets（也就是前面的css鏈）加載完成之后，才會開始渲染整個頁面，在此之前，瀏覽器不會渲染頁面里的任何內(nèi)容，頁面會一直呈現(xiàn)空白（這也是一些網(wǎng)站前幾秒空白的主要原因之一）。這也是為什么要把 stylesheet 放在頭部的原因。如果放在 HTML 頁面底部，頁面渲染就不僅僅是在等待 stylesheet 的加載，還要等待 html 內(nèi)容加載完成，這樣一來，用戶看到頁面的時間會更晚。順帶說下現(xiàn)在很早不用@import也是因為，它的處理方式是將css <link> 標簽放在頁面的底部加載。

二、關(guān)于圖片屬性with和height是否多余？
在我們實際的運用中，相對有經(jīng)驗點的前端在img的外部都會有相對的包裹也就是parent box來限制圖片的寬高，避免二.B的產(chǎn)品傳錯圖片搞亂整個頁面布局，處理這個問題的方法每個前端可能都不同有的是定義父級的寬高然后在進行overflow:hidden；而有的可能是直接繼承或者給圖片類來設(shè)置死圖片的高寬，那這個時候問題來了，我們這里已經(jīng)對圖片做了諸多針對二.B的保護措施，那圖片的這個2個屬性是否多余了？NO，在這里我們首先必須肯定前輩們設(shè)置的每個屬性標簽都是有它存在的價值和經(jīng)過諸多考慮的（當然隨著互聯(lián)網(wǎng)的發(fā)展，廢去的諸多標簽屬性，并不是前輩考慮不周而且互聯(lián)網(wǎng)進步實在太快了），在css 的渲染過程中，它是逐一渲染堆疊的（和疊沙樓一樣先渲染完前面的才繼續(xù)往下渲染），而在這個堆疊渲染的過程中當已渲染元素的寬高等layout改變時會重新回頭開始渲染（這也就是所謂的回流），而在頁面加載過程中從html的讀入到css的渲染，圖片加載總是會慢人一步（很多情況下css讀寫完畢后圖片可能還并未加載出來），因此指定的所有圖像的寬度和高度可以通過消除不必要的回流與重繪需要更快的渲染，當然對于父級已經(jīng)固定寬度的行為這里img的屬性也就相對沒有那么重要了。
說到圖片這里順帶說下，不要對圖片進行縮放也就是圖片的實際大小大于他的顯示必要，比如一個800*600的圖片，而我們在頁面上只顯示的是400*300的大小，那么這便是一種服務(wù)器資源的浪費（當然這個其實完全要看后期產(chǎn)品維護了），同時alt這個屬性千萬別偷懶，或許這個屬性在正常情況下基本沒用處而且浪費字節(jié)，但是對于灰色世界的盲人來說圖片他們是看不到的，而alt才能告訴他們這是一張什么樣的圖。

三、css選擇符越詳細越好嗎？為什么？
其實這個問題，我想很多前端都不會犯，但是對于新人或者涉足不深的人來說偶爾不經(jīng)意間還是會寫出來，在說這個前，首先我們應(yīng)該知道css的查找方式和js的不同，總所周知js查找元素是從上向下的查找，也就是先查找到父級，接著在是子級，而css則相反，它的屬性選者符是從后向前查找的，比如.class .a則是先會遍歷整個dom樹查到類名為a的元素接著在繼續(xù)向上查在這個元素的父級上有沒有一個類名為class的元素，因此對于屬性選擇符則是越簡略越好（當然基于模塊化卻不能完全執(zhí)行這個準則），因為這樣會加快查找速度（無需根據(jù)上級類去一一匹配），同時也會方便你的維護和修改，除了性能還能方便維護和修改，因為對于選擇符優(yōu)先級，越詳細則寫的越深（即層次越多）那當下個元素需重用覆蓋的時候必須要寫比前者更高的優(yōu)先級層次，那么這樣的模塊越多你的代碼也就疊加的越高，而且對于以后的模塊遷移調(diào)整起來更加是場災(zāi)難；例如要定義div .a 下的 ul 中的所以li的字符大小 .a ul li{font-size:12px;}這樣中的ul是遠遠多余的因為li本身就是不可能單獨存活的，當然如果你a中有ol的話那我更加建議給ol和ul分布加上類去單獨定義；

四、expression為什么不建議用？以及＊通配符為什么也不建議用？
對于萬惡的ie6中最小寬高不得不說是比較讓人郁悶的東西之一，而那個時候expression閃閃發(fā)光的跳了出來，后來漸漸隱沒當然還是有那么一小撮懷舊的偶爾會用用，很多人只知道用它性能不好也就不用了，但是卻不知道為什么性能不好，其實相對的來說在css中能直接運用expression這樣的js表達式來處理一些簡單的事情還是比較前衛(wèi)和值得開心的（當然這樣和分離有點背道而馳了），但是不幸的是這個屬性僅僅是ie特有的，而且它運用起來性能存在嚴重的問題，它的問題就在于它的計算頻率要比我們想象的多，不僅僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動鼠標時都會要重新計算一次，大家可以做個測試在這個表達式中增加一個計數(shù)器來跟蹤表達式的計算頻率，最后在頁面中隨便移動鼠標，可以看到它輕松達到10000次以上的計算量，想想這鬼東西背著我們在后面吃了我們多少內(nèi)存。所以真愛用戶遠離expression，其實針對ie6對于寬高的處理特性來說換個方向，它是遠遠都足夠表現(xiàn)最小寬高的（ie6對于寬高處理方式是元素大于父級時會撐大容器而不是溢出），當然最大寬高的解決方案相信親都不用我說了這里也就節(jié)約下力氣。
然后我們說說通配符，我記得在08年那段時間通配符真是個神器，為我們可是省了不少力氣，大家那個時候都愛用它，甚至很多書本也會專門的劃出一部分來講它，但如今相信很多人都不用說已經(jīng)開始擯棄它了，大家都有了一套自己的reset小庫或者小段落，但是為什么這么省事的東西現(xiàn)在大家卻想法不用呢？因為對于＊它會遍歷所有的dom去一一的執(zhí)行我們定義的樣式，那這可真不是個小工程，就像大家以前最常用的＊｛margin：0；padding：0｝這個會設(shè)置所有的元素內(nèi)邊矩和外邊距，但是在實際情況中并不是所有的元素都需要這樣做，那它帶來的就是負擔了，同時也盡量要避免類名下直接定義通配符，這樣做瀏覽器會匹配文檔中所有的元素后分別向上逐級匹配這個類的元素，直到文檔的根節(jié)點，其匹配開銷非常大，通常比開銷最小的ID選擇器高出1~3個數(shù)量級，所以也要避免使用關(guān)鍵選擇器是通配選擇器的規(guī)則。（關(guān)于css選擇符及性能更詳細可以看看https://developers.google.com/speed/docs/best-practices/rendering?hl=zh-TW）

五、css合并圖片是越多越好嗎？
現(xiàn)在對于超鏈過多請求影響網(wǎng)頁加載是大家總所周知的一件事，大家都會習慣圖片合并成一張，來獲取更好的性能，在這樣做的同時也付出了一定的代價，圖片的體積更大了，更有甚者一張圖高達200多K，這樣圖片帶來的效果是否會真的更加好？我們都知道這樣合并之所以好，是因為它減少了從服務(wù)器多余的請求所消耗的等待時間，比如10張4k的圖片那就要請求10次，最后的總大小也就是40k，但是圖片合并到一張后只需請求一次，而且合并后的圖片可能并不會大于這40k（合并的圖片要比分離的圖片的總和要小，因為它降低了圖片自身的開銷如顏色表、格式信息等），這其余的九次請求也就是節(jié)約來的性能，但是事情也是相對的，請求次數(shù)是少了，但是服務(wù)器承載的負擔卻會比開始大大增加同時以太網(wǎng)最大傳輸單元MTU為1500字節(jié)而當我面合并的圖片過大時會最大限度地加大動態(tài)和靜態(tài)資源的有效載荷大小增加網(wǎng)絡(luò)延遲。對于一個大型的門戶網(wǎng)站來說一張200K的圖片每天幾十萬幾百萬的請求對服務(wù)器的承載負擔是相當重的，在css和頁面渲染完畢后背景圖片會姍姍來遲所帶來的交互也是很不好的，同時對于后期的按鈕等修改帶來的維護成本也很高，所以這里建議合理運用。（更詳細的可以可以看看https://developers.google.com/speed/docs/best-practices/payload?hl=zh-TW）

六、table真的那么可惡不要運用嗎？還有html怎么去優(yōu)雅合理運用？
現(xiàn)在很多面試都會問是div+css嗎？不用表格的吧？（當然前幾年比較多，現(xiàn)在都改為會css3和html5，我擦）其實這樣問的多數(shù)都是你未來的lead，對于表格其實我想說它真的很冤枉，它自身對于數(shù)據(jù)的展示是無可取代的，雖然在強大的css下ul、ol甚至div都可以完美的來達到這個效果，但是我想說現(xiàn)在我們做的事和多年前去用表格布局有什么不同呢？所以施主放過table吧， table它的存在對于數(shù)據(jù)的展示本身就是它重要的使命否則為啥沒用在廢除b這樣的標簽的時候干掉它呢？當然table確實也是有它的局限性，總之合理應(yīng)用（數(shù)據(jù)展示最終也要看標準和展示形式）。
對于html的合理應(yīng)用，其實最重要的是理解標簽的語義，在這里我推薦個文章就不在啰嗦了。

如果有更多的為什么不清楚的可以留下來大家共同討論

最新評論