大家好，关于contenteditable很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于act和action的区别的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！
在HTML的世界里，内容编辑是一个让网页变得更加生动、互动的重要功能。而其中，`contenteditable` 属性便是实现这一功能的利器。今天，我们就来深入探讨一下这个属性，看看它是如何让网页变得更加灵活和有趣的。
什么是 `contenteditable`？
我们先来了解一下 `contenteditable`。简单来说，它是一个布尔属性，用于指定一个元素的内容是否可以被编辑。当这个属性被设置为 `true` 时，元素的内容就可以被用户编辑；如果设置为 `false`，则元素的内容将无法被编辑。
如何使用 `contenteditable`？
使用 `contenteditable` 非常简单，只需要在元素上添加这个属性即可。下面是一个简单的例子：
“`html
很多年以前，稍等，让我搜一下contenteditable（右上角），哈，是2010年的时候，写了篇文章“div模拟textarea文本域轻松实现高度自适应”，就是说的contenteditable的应用。
虽然说，利用全浏览器都支持的contenteditable模拟文本域可以实现体验相当不错的高度跟随内容自动撑开的效果，但是呢，有个很大的问题就是HTML内容可以直接被粘贴进去，如下图所示：
之前的文章提到过过滤HTML的方法，保证内容都是纯文本。然而，这种方法的问题在于：
粘贴完毕到过滤结束有时间差，用户很看到内容一闪而过的糟糕体验；
光标的位置会发生变化，不是之前focus的位置了；
当年的我图样图森破，所以，只有上面这种程度。实际上，控制contenteditable元素只能输入纯文本是有体验比较好的方法的。
二、与contenteditable属性无关的CSS控制法
一个div元素，要让其可编辑，也就是可读写，contenteditable属性是最常用方法，做前端的基本上都知道。但是，知道CSS中有属性可以让普通元素可读写的的同学怕是就少多了。
主角亮相：user-modify.
支持属性值如下：
user-modify: read-only;
user-modify: read-write;
user-modify: write-only;
user-modify: read-write-plaintext-only;
其中，write-only不用在意，当下这个年代，基本上没有浏览器支持，以后估计也不会有。read-only表示只读，就是普通元素的默认状态啦。然后，read-write和read-write-plaintext-only会让元素表现得像个文本域一样，可以focus以及输入内容。
您可以狠狠地点击这里：CSS user-modify属性行为表现demo
会发现，设置了read-write和read-write-plaintext-only值的两个<p>标签元素是可以被focus的：
而这两者的区别就在于，一个可以输入富文本，而下面一个只能输入纯文本，例如，我们从某网页同时复制一段内容粘贴进去看看：
好了，至此，本文标题的答案实际上就已经有了。也就是给元素设置：
user-modify: read-write-plaintext-only
就可以让元素既可以编辑，也只能输入纯文本，表现得就跟textarea文本域一样。
是不是很酷啊！然而，抱歉地跟大家讲下，目前只有webkit内核浏览器才支持read-write-plaintext-only这个值，因此，我们的使用其实是：
-webkit-user-modify: read-write-plaintext-only
我们可以在移动端使用，以及，只需要兼顾webkit内容的桌面网页项目。
三、使用标准contenteditable属性值的HTML控制法
咳咳，提问：在HTML中，contenteditable支持的属性值是？
图样图森破时候的我，脑中就只有contenteditable=”true”和contenteditable=”false”，科科，后来我发现自己太天真了，新的草案中明确表示还有多个其他属性值：
The contenteditable attribute is an enumerated attribute
whose keywords are the empty string(“”),“events”,“caret”,“typing”,
“plaintext-only”,“true”, and“false”. There is one additional state,
the inherit state, which is the missing value default(and the invalid
value default).
垂直展示下就是（不包括默认的inherit继承）：
contenteditable=””
contenteditable=”events”
contenteditable=”caret”
contenteditable=”plaintext-only”
contenteditable=”true”
contenteditable=”false”
别问我，我也不知道”events”和”caret”是干什么用的，嘿，但是”plaintext-only”我是知道的，可以让编辑区域只能键入纯文本。这里就不需要demo了，直接下面的框框，大家可以试试，看看能不能搞富文本。
<div contenteditable=”plaintext-only”></div>
如果您发现，居然出乎意料，可以弄进去富文本，那说明你使用的是非Chrome之流的浏览器。
换句话说，contenteditable=”plaintext-only”和CSS只的-webkit-user-modify: read-write-plaintext-only一样，目前仅仅是Chrome浏览器支持比较好的。
所以，您的项目如果还有很多IE8浏览器的用户，我只能替你惋惜，美妙的东西无法立即用上，不得已，寻求下面的方法。
四、控制粘贴paste事件的JS控制法
如果我们单纯地敲击键盘，输入的内容实际上都是纯文本。除了一些特殊情况，例如IE浏览器下的编辑框会自动把合乎条件的url地址自动加上链接。富
文本污染的情况主要出现在复制粘贴的时候，于是，如果我们能在粘贴的时候，对剪切板中的内容进行HTML过滤，再手动插入内容，岂不就可以完美解决无法输
入富文本的问题了吗
元素为contenteditable时,内容为空,光标显示异常
问题可能由元素为空、嵌套不可编辑元素、浏览器兼容性等原因导致，以下是解决办法：
空内容时光标不显示元素内插入 （非换行空格），如<div contenteditable="true"> </div>。通过 CSS确保最小高度，如.editable{ min-height: 20px;}。嵌套不可编辑元素后光标异常在不可编辑元素后添加<br>或 ，如<div contenteditable="true"><span contenteditable="false">固定文本</span> </div>。通过 JavaScript控制光标位置，点击不可编辑元素时将光标移至末尾。浏览器兼容性差异Firefox删除含 contenteditable="false"的元素时需额外处理，可通过 JS监听删除事件。Chrome默认允许删除不可编辑元素，但光标定位可能偏移，需通过 getSelection()手动调整。其他优化建议使用 contenteditable="plaintext-only"（部分浏览器支持）限制纯文本输入，减少格式混乱。避免空标签嵌套，确保初始内容非空，可插入空格或换行。结合 CSS隐藏默认聚焦轮廓，如.editable:focus{ outline: none;}。设置 placeholder，通过 CSS:empty伪类模拟占位符。清除多余标签，用 JS过滤删除时残留的<br>标签。重置后光标定位，清空内容后，通过 Range和 Selection API将光标定位到末尾。聚焦时强制显示光标，确保元素获得焦点时光标可见。
ios使用wangeditor的restoreselection获取不到正确的焦点位置
在iOS系统中使用WangEditor时，若restoreSelection无法获取正确焦点位置，可通过调整编辑器属性、注释特定代码、优化事件监听等方式解决，但需注意移动端光标定位仍存在局限性。
1.调整contenteditable属性与CSS样式iOS系统对可编辑元素的渲染机制与桌面端不同，可能导致焦点定位异常。需确保编辑器容器明确设置为contenteditable="true"，并通过CSS优化聚焦行为：
添加-webkit-user-select: text，允许iOS设备正常选择文本；设置outline: none，避免默认焦点轮廓干扰定位；确保父元素未设置user-select: none或pointer-events: none等阻止交互的属性。此方法通过修正元素的可编辑状态与渲染样式，可解决部分因系统兼容性导致的焦点偏移问题。2.注释或移除restoreSelection相关代码WangEditor的restoreSelection方法在移动端可能因选区恢复机制不兼容而失效。若无需保留选区状态，可直接注释掉调用该方法的代码行（如this.selection.restoreSelection()）。此操作会跳过选区恢复步骤，转而依赖系统默认的焦点定位逻辑，虽可能降低编辑体验的连贯性，但能避免因选区恢复失败导致的焦点错位。
3.优化事件监听与自动聚焦配置iOS对事件拦截的敏感度较高，需检查以下配置：
移除selectstart事件拦截：若代码中存在document.addEventListener('selectstart', e=> e.preventDefault())，需删除或修改为条件性拦截，否则会完全阻止文本选择与焦点获取；设置autoFocus: false：强制自动聚焦可能导致iOS系统忽略手动触发的焦点请求，建议关闭此选项，由用户交互（如点击）触发聚焦；避免动态修改contenteditable状态：在聚焦期间切换contenteditable属性会导致iOS丢失焦点上下文，需确保编辑器状态稳定。4.明确移动端使用限制WangEditor作者明确指出，该编辑器的光标定位算法主要针对桌面端设计，移动端（尤其是iOS）的触摸交互、虚拟键盘弹出等场景可能引发不可预知的定位问题。若项目必须支持移动端，建议：
测试基础功能（如纯文本输入）的可用性，避免依赖复杂选区操作；考虑使用专为移动端优化的编辑器（如Quill的移动端适配版本或原生组件）。通过以上调整，可在iOS系统中改善WangEditor的焦点定位问题，但需权衡功能完整性与系统兼容性。
OK，关于contenteditable和act和action的区别的内容到此结束了，希望对大家有所帮助。
