技術(shù)面試題：
1.圖片批量上傳
咱之前做過一個(gè)圖片上傳的例子，其實(shí)只要進(jìn)行循環(huán)就可以了。
2.響應(yīng)式
對不同終端的進(jìn)行響應(yīng)。
3.html5去除了哪些內(nèi)容
第一類：表現(xiàn)性元素
basefont/big/center/font/s/strike/tt/u
建議用語義正確的元素代替他們，并使用CSS來確保渲染后的效果
第二類：框架類元素
因框架有很多可用性及可訪問性問題，HTML5規(guī)范將以下元素移除。
frame/frameset/noframes
但html5支持iframe。
第三類:屬性類
很多表現(xiàn)性的屬性也被新規(guī)范移除，如下：
align
body標(biāo)簽上的link、vlink、alink、text屬性
bgcolor
height和width
iframe元素上的scrolling屬性
valign
hspace和vspace
table標(biāo)簽上的cellpadding、cellspacing和border屬性
header標(biāo)簽上的profile屬性
鏈接標(biāo)簽a上的target屬性
img和iframe元素的longdesc屬性
第四類：其他
abbr取代acronym（用于表示縮寫）
object取代了applet
ul取代了dir
4.如何區(qū)別html和html5
1.在文檔類型聲明上
html:
html5:
在文檔聲明上，html有很長的一段代碼，并且很難記住這段代碼，而html5卻不同，只有簡簡單單的聲明，這也方便人們的記憶。
2.在結(jié)構(gòu)語義上
html:沒有體現(xiàn)結(jié)構(gòu)語義化的標(biāo)簽，通常都是這樣來命名的
，這樣表示網(wǎng)站的頭部。
html5:在語義上卻有很大的優(yōu)勢。提供了一些新的標(biāo)簽，比如:。
5.sessionstorage和localstorage和cookie
共同點(diǎn)：都是保存在瀏覽器端，且同源的。
區(qū)別：cookie數(shù)據(jù)始終在同源的http請求中攜帶（即使不需要），即cookie在瀏覽器和服務(wù)器間來回傳遞；cookie數(shù)據(jù)還有路徑（path）的概念，可以限制cookie只屬于某個(gè)路徑下。存儲大小限制也不同，cookie數(shù)據(jù)不能超過4k，同時(shí)因?yàn)槊看蝖ttp請求都會攜帶cookie，所以cookie只適合保存很小的數(shù)據(jù)，如會話標(biāo)識。
而sessionStorage和localStorage不會自動(dòng)把數(shù)據(jù)發(fā)給服務(wù)器，僅在本地保存。sessionStorage和localStorage 雖然也有存儲大小的限制，但比cookie大得多，可以達(dá)到5M或更大。
數(shù)據(jù)有效期不同，sessionStorage：僅在當(dāng)前瀏覽器窗口關(guān)閉前有效，自然也就不可能持久保持；localStorage：始終有效，窗口或?yàn)g覽器關(guān)閉也一直保存，因此用作持久數(shù)據(jù)；cookie只在設(shè)置的cookie過期時(shí)間之前一直有效，即使窗口或?yàn)g覽器關(guān)閉。
作用域不同，sessionStorage不在不同的瀏覽器窗口中共享，即使是同一個(gè)頁面；localStorage 在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。Web Storage 支持事件通知機(jī)制，可以將數(shù)據(jù)更新的通知發(fā)送給監(jiān)聽者。Web Storage 的 api 接口使用更方便。
6.圖片預(yù)覽功能
咱做過一個(gè)關(guān)于圖片預(yù)覽，圖片上傳后會進(jìn)行預(yù)覽，還有進(jìn)度條
7.第三方登錄
百度查，會有很多接口。
8.iframe優(yōu)缺點(diǎn)
注：HTML5不再支持使用frame，iframe只有src 屬性
一、使用iframe的優(yōu)缺點(diǎn)
優(yōu)點(diǎn):
1.程序調(diào)入靜態(tài)頁面比較方便;
2.頁面和程序分離;
缺點(diǎn)：
1.iframe有不好之處：樣式/腳本需要額外鏈入，會增加請求。
另外用js防盜鏈只防得了小偷，防不了大盜。
2.iframe好在能夠把原先的網(wǎng)頁全部原封不動(dòng)顯示下來,但是如果用在首頁,是搜索引擎最討厭的.那么你
的網(wǎng)站即使做的在好,也排不到好的名次!
如果是動(dòng)態(tài)網(wǎng)頁，用include還好點(diǎn)！
但是必須要去除他的<body>標(biāo)簽！
3.框架結(jié)構(gòu)有時(shí)會讓人感到迷惑，特別是在多個(gè)框架中都出現(xiàn)上下、左右滾動(dòng)條的時(shí)候。這些滾動(dòng)條除了
會擠占已經(jīng)特別有限的頁面空間外，還會分散訪問者的留心力。訪問者遇到這種站點(diǎn)往往會立刻轉(zhuǎn)身離開
。他們會想，既然你的主頁如此混亂，那么站點(diǎn)的其他部分也許更不值得閱讀。
4.鏈接導(dǎo)航疑問。運(yùn)用框架結(jié)構(gòu)時(shí)，你必須保證正確配置所有的導(dǎo)航鏈接，如不然，會給訪問者帶來很大
的麻煩。比如被鏈接的頁面出現(xiàn)在導(dǎo)航框架內(nèi)，這種情況下訪問者便被陷住了，因?yàn)榇藭r(shí)他沒有其他地點(diǎn)
可去。
5.調(diào)用外部頁面,需要額外調(diào)用css,給頁面帶來額外的請求次數(shù);
二、為什么少用iframe
iframes 提供了一個(gè)簡單的方式把一個(gè)網(wǎng)站的內(nèi)容嵌入到另一個(gè)網(wǎng)站中。但我們需要慎重的使用iframe。iframe的創(chuàng)建比其它包括scripts和css的 DOM 元素的創(chuàng)建慢了 1-2 個(gè)數(shù)量級。
使用iframe 的頁面一般不會包含太多 iframe，所以創(chuàng)建 DOM 節(jié)點(diǎn)所花費(fèi)的時(shí)間不會占很大的比重。但帶來一些其它的問題：onload 事件以及連接池(connection pool)。
1.Iframes 阻塞頁面加載
及時(shí)觸發(fā)window 的 onload 事件是非常重要的。onload 事件觸發(fā)使瀏覽器的 “忙” 指示器停止，告訴用戶當(dāng)前網(wǎng)頁已經(jīng)加載完畢。當(dāng) onload 事件加載延遲后，它給用戶的感覺就是這個(gè)網(wǎng)頁非常慢。
window 的 onload 事件需要在所有 iframe 加載完畢后(包含里面的元素)才會觸發(fā)。在 Safari 和 Chrome 里，通過 JavaScript 動(dòng)態(tài)設(shè)置 iframe 的 SRC 可以避免這種阻塞情況。
2.唯一的連接池
瀏覽器只能開少量的連接到web服務(wù)器。比較老的瀏覽器，包含 Internet Explorer 6 & 7 和 Firefox 2，只能對一個(gè)域名(hostname)同時(shí)打開兩個(gè)連接。這個(gè)數(shù)量的限制在新版本的瀏覽器中有所提高。Safari 3+ 和 Opera 9+ 可同時(shí)對一個(gè)域名打開 4 個(gè)連接，Chrome 1+, IE 8 以及 Firefox 3 可以同時(shí)打開 6 個(gè)。你可以通過這篇文章查看具體的數(shù)據(jù)表：Roundup on Parallel Connections.
有人可能希望iframe 會有自己獨(dú)立的連接池，但不是這樣的。絕大部分瀏覽器，主頁面和其中的 iframe 是共享這些連接的。這意味著 iframe 在加載資源時(shí)可能用光了所有的可用連接，從而阻塞了主頁面資源的加載。如果 iframe 中的內(nèi)容比主頁面的內(nèi)容更重要，這當(dāng)然是很好的。但通常情況下，iframe 里的內(nèi)容是沒有主頁面的內(nèi)容重要的。這時(shí) iframe 中用光了可用的連接就是不值得的了。一種解決辦法是，在主頁面上重要的元素加載完畢后，再動(dòng)態(tài)設(shè)置 iframe 的 SRC。
美國前10 大網(wǎng)站都使用了 iframe。大部分情況下，他們用它來加載廣告。這是可以理解的，也是一種符合邏輯的解決方案，用一種簡單的辦法來加載廣告服務(wù)。但請記住，iframe 會給你的頁面性能帶來沖擊。只要可能，不要使用 iframe。當(dāng)確實(shí)需要時(shí)，謹(jǐn)慎的使用他們。
以上答案供參考。
