防止删除内容可编辑<ul>中的所有<li>标记

Question

当您<li>在内容可编辑<ul>标记内一直退格到标记的开头时,<li>将删除所有剩余标记.

<ul contenteditable="true">
    <li>Hello</li>
    <li>World</li>
</ul>

jsfiddle:http://jsfiddle.net/8Q53V/

将光标放在世界中的'd'后面,然后退回到行的开头.再次点击退格键时,它也会删除"Hello"列表项.你怎么能防止这种行为？

更新:看起来此行为仅存在于Chrome中

Answer 1

这是我发现的:

如果父ul元素后面没有最小渲染空间为1px x 1px的任何其他元素,则只会出现Opera和Chrome中的可疑列表的错误行为.display元素的值无关紧要,只要它是非空的或具有CSS的设置高度维度即可.

所以添加一个简单的<div style="height: 1px;">将回答你最直接的问题.

但是,contenteditable在询问时,您无法可靠地使用HTML中的列表.

这个问题引起了我的兴趣,我在Win 8.1上测试了Moz FF 29-30,Opera 21,Google Chrome 35和IE 11.我测试了简单的键,如Enter,Backspace和Delete.

TL; DR:IE 11完全搞砸了,如果ul后面跟着一个渲染大小的元素,那么Opera和Chrome会做得很好,并且Moz FF会插入一个奇怪的<br type="_moz"></br>标签.你会需要e.preventDefault(),e.keyCode/charCode以及Selection与RangeJS API来创建在所有浏览器都能正常工作的自定义列表CONTENTEDITABLE.但是,这些先决条件在所有浏览器上都不能始终如一.最佳解决方案:使用现有编辑器或一些不可见的文本输入进行输入.

这些是详细的问题:

点击Enter添加新的li将添加以下标记:

• Opera和Google Chrome:<li><br><li>
• Moz FF:<li><br type="_moz"></br>
• IE 11:如果active li是非空的:<li><br></li>如果它是空的,IE完全混乱并插入一个p,然后<ul contenteditable="">在它之后复制一个空,只有一个<br>标签在里面.这个空ul将被添加后,原来的元素之后的元素,如果有的话.

击中Backspace删除li:not(:first-child)将执行以下操作:

• Opera和谷歌浏览器:如果ul后面没有一个具有渲染大小的元素,那么所有的元素都li将被删除.如果是,则发生预期的行为.(一个li被删除).
• Moz FF:发生预期的行为(一个li被删除).但是,删除a后,Moz FF会将光标移出可信区域li.
• IE 11:与击中时相同的行为Enter.

击中Backspace删除第一个li 应该不惜一切代价阻止.

对于每个测试的浏览器,这会打破列表布局.所有新Enter命中都将生成div列表中的直接子项.

击中Delete除去随后li在所有测试的浏览器一贯的作品.随后li将被删除,其中的任何内容将被转移到当前li

在空白处键入第一个字母li将执行以下操作:

• Opera,IE11和谷歌Chrome:这封信是打印出来的.自动插入的<br>标签已删除.
• Moz FF:这封信被打印出来.自定义<br type="_moz">标记未删除.

删除空白中的唯一字母li将执行以下操作:

• Opera,IE11和Google Chrome:<br>自动插入另一个标签.
• Moz FF:没什么.习俗<br type="_moz">仍然存在.

小提琴:http://jsfiddle.net/8Q53V/8/(第一个ul是自定义编码行为,不完美,第二个ul是标准的)