html5給大多數元素都增加了contentEditable屬性，如果給某元素設置屬性 contentEditable = "true"，那麼該元素就會進入可編輯狀態，即瀏覽器會允許用戶直接編輯該元素內容。
html:
<div class="wraper">
<div contenteditable="true">
<p>這裏的文字是可編輯的</p>
</div>
</div>
css:
div.wraper {
width: 240px;
height: 240px;
position: relative;
margin: 100px;
}
.wraper div {
position: absolute;
top: 0;
left: 0;
bottom: 0;
right: 0;
width: 200px;
height: 200px;
background: #f0b921;
box-sizing: border-box;
border-radius: 4px;
margin: auto;
}
p {
color: #fff;
margin: 15px;
display: inline-block;
}
默認情況下，div是不可編輯的
當我們設置contenteditable="true"後，鼠標點擊後，谷歌瀏覽器下，div多了一個藍色的邊框（outline），如下：
當我們按下刪除鍵，節點會被清空
可是當我們按下回車鍵時，神奇的一幕出現了，產生兩個div節點，節點內還有一個換行符！
也就是說，"一個回車" == "兩個div節點"？
真真假假，試過便知。事實上是，之後不管按多少次回車，谷歌瀏覽器下都只產生一個節點。
在這裏，咱把思路稍微拓寬一些，首先，拋出一個疑問：是不是其他瀏覽器下，都是這樣呢？
作死測試1：Microsoft Edge （別問我爲什麼用這個測試，順手...）
查看控制檯：設置了contenteditable的div下面沒有顯示任何子節點（額外的元素作死測試我就不試了，不在本文討論範圍內）
結果：不論按刪除還是多次回車，控制檯雷打不動，沒有任何改變
作死測試2：火狐
查看控制檯：設置了contenteditable的div下面產生了兩個p節點，節點內有一個換行符
結果：按下刪除，生成一個p節點，節點內有一個換行符。按下回車，生成倆~
作死測試3：萬惡的ie(IE11)
查看控制檯：設置了contenteditable的div下面產生了兩個p節點，節點內有一個換行符
結果：按下刪除，真的清空了這個div。按下回車，生成倆p節點，但節點裏面沒有換行符
作死結束。
作死總結：經過一番折騰，縷清了不同瀏覽器對contenteditable屬性的不同解釋，而這卻很有可能產生對用戶體驗有一定影響的bug。
作死外話：在測試的過程中發現，如果在設置了contenteditable屬性的div元素內存在div元素(假設名爲child），則裏面的div元素child會出現以下情況（目前僅測試谷歌、火狐、IE11環境下）：
- 谷歌、火狐、IE11下，完全覆蓋其父元素
- 谷歌、火狐、IE11下，該child元素的內容不顯示，但在控制檯可見
- 火狐、IE11下，該child元素可被編輯，但在IE下，快速拉伸會導致“側漏”現象，即拉伸過程中留下殘影
- 谷歌下，該child不可編輯
作死發現：contenteditable屬性其實是可繼承的，如果父元素可編輯，則子元素也可以編輯，除非手動設置contenteditable="false"
除此之外，html5還給設置了contenteditable屬性的元素提供了isContentEditable屬性，當元素可編輯時，該屬性返回true，否則返回false。
那麼問題來了，咱是不是還可以通過isContentEditable屬性對用戶的操作做一些不可描述的騷操作呢？（手動滑稽）