前端思考題

1.站點 Logo 是否應出如今標籤中？

 

2.是否應該支持IE6？

 

3.前端網頁製做怎麼克服不一樣分辨率的問題？

　　根據屏幕不一樣大小，縮小窗口出橫向滾動條在所不免，但理想狀況下，頁面應該能適應不一樣客戶端瀏覽器和分辨率。實際操做一般又有三種狀況：版面自適應、視覺自適應、內容自適應。具體要怎樣實現呢？

 

4.是否該繼續使用 <b> 和 <i> 兩個標籤?

　　正方：

　　若是你僅僅想把一個詞設爲粗體，而這個詞並無強調錶示重要的意思，應該使用 <b> 標籤，不應用 <strong> 標籤，讀屏軟件對 　<b> 和<i> 標籤有不一樣的發音，而 HTML5 規範中仍包含這兩個標籤。

　　反方:

　　這兩個標籤的做用是將文字設置爲粗體或斜體，從語義角度看，任何裝飾性的東西都應該使用 CSS 實現，若是要強調一個詞語，應該使用 <strong> 或 <em> 標籤。

　　和事佬：

　　<b> 和 <i> 標籤不該該用於修飾文字的式樣，這些視覺的修飾應該交由 CSS 處理。若是要強調一個詞彙或語句，應該使用 <strong> 或 <em> 標籤。只有在那些沒有別的標籤可用的場合，才能夠考慮 <b> 和 <i> 。

 

5.在連接中應該使用諸如「Click here」 一類的籠統詞彙嗎？

　　正方:

　　事實證實，「Click here」 比描述性的連接更容易得到點擊，所以應該使用該詞彙以得到更好的點擊率。

　　反方:

　　「Click here」 一類的連接損害 Web 的易用性，用戶在點擊以前，只能經過周圍的上下文關係猜想這個連接是作什麼的。Quality guidelines 建議，任何連接文字都應該明確描述該連接的目的。

　　和事佬:

　　爲了提升站點的易用性，可訪問性和 SEO 性能，應該始終使用描述性連接。頗有趣聽到有人說 「Click here」 比描述性連接能夠得到更多點擊率，不知道那些點擊進來的人是否是看兩眼就離開了。

 

6. 連接是否應該在新窗口打開？

　　在 Web 空前繁榮的今天，有關 Web 設計中的各類觀點不少會成爲話題，有的很快達成一致，有的則一直爭議下去。

　　正方:

　　外部連接應該始終重新窗口打開，當你瀏覽一個站點的時候，點擊了一個連接，卻被帶到另一個站點，你在這個站點的會話也所以丟失，這實在使人惱怒。所以，站點內的連接能夠在現有窗口打開，而站點外連接則應該在新窗口打開。

　　反方:

　　做爲 Web 設計師，咱們不應控制用戶的行爲，一個連接是否在新窗口打開，應該是用戶本身的選擇。剝奪用戶的控制權，在用戶的桌面上打開一堆窗口或標籤，這纔是真正讓 人惱怒的事。若是用戶想打開新窗口，他們能夠本身選擇，而對非熟練用戶，新窗口讓他們丟失了「後退」按鈕更讓他們無所適從。

　　和事佬:

　　整體來說，應該避免使用新窗口打開連接，但在某些場合，如打開購物車中的幫助連接，打開一個非 html 文件（如 PDF 文件），應該使用新窗口。爲了提升易用性，最好在須要打開新窗口的地方，用一個小圖標提示一下。

 

7.時至今日前端canvas仍是否有深刻學習的必要？

　　如今手機和PC的性能愈來愈好，並且adobe animation、bodymovin和lottie等工具也漸漸進入大衆的視野，彷佛通常狀況下的需求均可以由設計完成。徒手寫酷炫的canvas的技能彷佛愈來愈邊緣化了，人寫與軟件生產最大區別是什麼？是性能問題嗎？按照目前硬件發展速度，性能還會是一個問題嗎？canvas自己學習成本高，開發思惟和通常意義前端不一樣，誠然尖端的遊戲引擎、渲染、數據可視化、webgl方面確定是須要人才的，可是低端的可替代性，其陡峭的學習曲線，是否能夠說明其生態的惡化？低端的人沒有實踐場景我以爲是很難走到高端的。

 

8.你如何對網站的文件和資源進行優化?

　　有效的解決方案包括：

　　文件合併

　　文件最小化/文件壓縮

　　使用CDN託管

　　緩存的使用

 

9.ajax請求的時候get 和post方式的區別是什麼？

　　區別在：

　　　　一個在url後面，一個放在虛擬載體裏面

　　　　有大小限制

　　　　安全問題

　　應用不一樣：一個是論壇等只須要請求的，一個是相似修改密碼的。

 

10. Web前端密碼加密是否有意義？(既然前端代碼都是直接能夠看到的，那加密是否還有意義？)

　　我總結一下，首先你們都知道走 HTTPS 纔是目前惟一負責的方式。但在 HTTP 環境下，不管如何均可能會被劫持流量，無論前端作不作加密都會被輕易成功登陸。這個時候保護密碼明文是否有意義？有人站隊前端加密無心義，考慮的是這個加密對本站的安全性沒有任何提高；但若是你是從保護用戶的角度出發，用戶多站點共享密碼是現狀，你在無法改變這一點的狀況下，若是可以保護密碼明文，至少下降了一點該用戶其餘網站（即便是 HTTPS 的網站）被一鍋端的風險。這怎麼能說徹底沒有意義？有人說 HTTP 流量能夠直接注入腳本，直接拿到用戶輸入的密碼，這沒錯。可是注入腳本就是代價，只要可以提升一點點門檻就不能說沒有意義，不少時候是這些收益和成本之間的權衡。

 

11.前端開發中有什麼經典的輪子值得本身去實現一遍？

　　我造過的輪子：LiuJi-Jim/jas：異步控制的工具，11年寫的，只有60行，然而炒雞好用，吃本身狗食的級別。LiuJi-Jim/raze-tpl：模板引擎，語法風騷迷人，吃本身狗食的級別。LiuJi-Jim/mirror：Virtual-DOM實現，玩具級別。LiuJi-Jim/h5pal：萬噸巨輪，仙劍奇俠傳web移植（介紹）。LiuJi-Jim/c-struct：一個用於JS讀寫C結構體的工具，從h5pal裏拆出來重構的。還有一些爛尾了，還有一些不想發出來的，各類Promise、EventEmitter、Module Loader、山寨Lodash、數據結構、類工廠、MVC……不提也罷。

 

12.在你的平常開發中遇到過哪些經常使用佈局是沒法用純 CSS 實現的？

　　1. 多行文字溢出顯示省略號

　　2. 最大行數

　　3. 更好用的 Flex

　　4. 元素查詢（Element Queries）

　　5. CSS 分頁滾動

　　6. 非矩形佈局

　　7. 流式 Grid 佈局

 

13.對前端工程師這個職位你是怎麼樣理解的？

　　a. 前端是最貼近用戶的程序員，前端的能力就是能讓產品從 90分進化到 100 分，甚至更好

　　b. 參與項目，快速高質量完成實現效果圖，精確到1px；

　　c. 與團隊成員，UI設計，產品經理的溝通；

　　d. 作好的頁面結構，頁面重構和用戶體驗；

　　e. 處理hack，兼容、寫出優美的代碼格式；

　　f. 針對服務器的優化、擁抱最新前端技術。

 

14.平時如何管理你的項目？

　　先期團隊必須肯定好全局樣式（globe.css），編碼模式(utf-8) 等；

　　1 編寫習慣必須一致（例如都是採用繼承式的寫法，單樣式都寫成一行）；

　　2 標註樣式編寫人，各模塊都及時標註（標註關鍵樣式調用的地方）；

　　3 頁面進行標註（例如 頁面 模塊 開始和結束）；

　　4 CSS跟HTML 分文件夾並行存放，命名都得統一（例如style.css）；

　　5 JS 分文件夾存放 命名以該JS功能爲準的英文翻譯。

　　6 圖片採用整合的 images.png png8 格式文件使用 儘可能整合在一塊兒使用方便未來的管理

 

15.如何視覺隱藏網頁內容，只讓它們在屏幕閱讀器中可用？

　　display:none;的缺陷搜索引擎可能認爲被隱藏的文字屬於垃圾信息而被忽略屏幕閱讀器（是爲視覺上有障礙的人設計的讀取屏幕內容的程序）會忽略被隱藏的文字。

　　visibility:hidden;的缺陷這個你們應該比較熟悉就是隱藏的內容會佔據他所應該佔據物理空間3.overflow:hidden;一個比較合理的方法.texthidden{display:block;/*統一轉化爲塊級元素*/overflow:hidden;width:0;height:0;}就像上面的一段CSS所展現的方法，將寬度和高度設定爲0，而後超過部分隱藏，就會彌補上述1、二方法中的缺陷，也達到了隱藏內容的目的。

 

16.你以爲WebAssembly爲何比asm.js快？

　　WebAssembly 爲何比 asm.js 快？

　　WebAssembly 是爲 Web 而設計的、能夠生成瀏覽器可執行的二進制文件的編程語言。而且於2017 年 2 月 28 日，四個主要的瀏覽器一致贊成宣佈 WebAssembly 的 MVP 版本已經完成，即將推出一個瀏覽器能夠搭載的穩定版本。WebAssembly 的一個主要目標就是變快。固然，「快」是相對的概念。相比於 JavaScript 和其餘動態語言，WebAssembly 的快主要是由於它的靜態類型特性和方便優化特性。WebAssembly 意在速度上可以達到和本地執行同樣快，其實 asm.js 已經比較接近這一目標了，可是 WebAssembly 要進一步縮短和本地執行速度之間的差距。

 

17.前端安全方面有沒有了解？CSRF 如何攻防？

 

18.說說你對 SVG 理解?

 

19.談談垃圾回收機制方式及內存管理.

 

20.開發過程當中遇到的內存泄露狀況，如何解決的？