任務 3 已經發布，初級班的任務時間是從 5 月 7 日至 5 月 18 日，中級班為 4 月 30 日至 5 月 10 日。
TASK 0003 內容：https://github.com/baidu-ife/ife/tree/master/task/task0003
我做的：https://github.com/DIYgod/ife-work/tree/master/task0003
在線 Demo： https://www.anotherhome.net/file/ife/task0003/
本次任務累計花費時間 10 天（5.6-5.16 ）
下面是我做 TASK 0003 過程中的一些記錄。
1. JavaScript 作用域 （參考 鳥哥：Javascript 作用域原理 理解 JavaScript 作用域和作用域鏈）
JavaScript 中的函數運行在它們被定義的作用域裡，而不是它們被執行的作用域裡。
JS 是有預編譯的過程的，JS 在執行每一段 JS 代碼之前，都會首先處理 var 關鍵字和 function 定義式 (函數定義式和函數表達式)。
在調用函數執行之前，會首先創建一個活動對象，然後搜尋這個函數中的局部變量定義和函數定義，將變量名和函數名都做為這個活動對象的同名屬性，對於局部變量定義，變量的值會在真正執行的時候才計算，此時只是簡單的賦為 undefined。
對代碼優化的啟示：
從作用域鏈的結構可以看出，在運行期上下文的作用域鏈中，標識符所在的位置越深，讀寫速度就會越慢。因為全局變量總是存在於運行期上下文作用域鏈的最末端，因此在標識符解析的時候，查找全局變量是最慢的。所以，在編寫代碼的時候應盡量少使用全局變量，盡可能使用局部變量。一個好的經驗法則是：如果一個跨作用域的對象被引用了一次以上，則先把它存儲到局部變量裡再使用。
例如下面的代碼：
這個函數引用了兩次全局變量 document，查找該變量必須遍歷整個作用域鏈，直到最後在全局對象中才能找到。這段代碼可以重寫如下：
這段代碼比較簡單，重寫後不會顯示出巨大的性能提升，但是如果程序中有大量的全局變量被從反復訪問，那麼重寫後的代碼性能會有顯著改善。
2. 高度自適應 （參考 CSS 布局奇淫技巧之 - 高度自適應）
高度自適應不像寬度自適應那樣簡單，在兼容瀏覽器方面也稍微複雜一些。
然而直接寫 height: 100%; 並沒有什麼卵用，要這樣做：
3. 莫名其妙出現又莫名其妙自己消失的空隙
事情是這樣的，昨天（5 月 12 日）頁面一切正常，今天早上起床後並沒改動代碼，刷新了一下頁面，頁面居然變了，設置 overflow: scroll CSS 屬性的元素右側和下側都出現了空隙，如圖所示：
而如果把 overflow: scroll 屬性去掉空隙就消失。測試 Chrome Safari 均出現了這種情況，而且嘗試了清空緩存，無解。於是將此時的代碼 commit 並 push 到了 github。
到了下午，同一標籤頁，同一頁面，刷新，bug 自己消失了，而此時代碼與上午相比只有很少且無關緊要的改動，再次 commit 並 push 到 github（所有改動在 github 有記錄），再次截圖：
注意：兩次出現變化後都嘗試測試了 Chrome 和 Safari 瀏覽器並清空了緩存。
到此為止毫無頭緒並無法重現，實在沒辦法再深究下去。
猜測是 Mac 的 Bug。
4. JavaScript 對象與 JSON 文本的相互轉換 （參考 JavaScript 對象與 JSON 字符串的相互轉換 JSON 教程 - W3CSCHOOL）
eval 函數：JSON 文本轉換為 JavaScript 對象；調用 JavaScript 編輯器；非常快速，但可能會出現安全性問題
使用 JSON 解析器：
JSON.parse 函數：將 JSON 文本轉換為 JavaScript 對象
JSON.stringify 函數：將 JavaScript 對象轉換為 JSON 文本
5. textarea 和 input 大小比預期大了一些
多謝李勝的幫助
這個問題其實很簡單但我沒想到，剛開始挺莫名其妙的，如下：
See the Pen RPaJpb by DIYgod (@DIYgod) on CodePen.
問題是 textarea 和 input 比設置的寬度多了 6px，強迫症看了渾身難受。實際上是因為這兩個元素有默認的 2px padding 和 1px border，在這兩個元素的 CSS 部分加上
或者更優雅一些
就好了。
☆ﾐ(o*･ω･)ﾉ完結散花 等待 review