所见即所得编辑器 inEdit 开发笔记(发现 mercury,考虑直接使用)
程序员文章站
2022-07-14 17:19:57
...
经过2年时间的沉寂,inEdit 又开始进行开发了,上一次停止开发,主要原因是
- 工作了,没时间开发,现在失业中,终于又有时间了
- 问题太多,没有找到好的解决方案
最近通过学习 CKEditor 和 UEditor 获得了一些思路,整理如下
主要兼容性问题
- range
也就是选择区域范围问题,必须处理成一致的接口和对边界进行处理,对于IE可以考虑使用 ierange
但是 ierange 有个BUG需要注意,在某些场景下获取 range text会出错
BUG更多无法用,采取UEditor的吧 - 回车
各个浏览器中差异很大,为了得到一致性有必要截获回车事件并通过代码来处理回车
问题衍生,如果选择了某个区域,那其实要先做删除处理,这个问题 UEditor 采用自己的代码完成
inEdit目前暂时使用 document.execCommand('delete',false,null); 解决,是否会造成一致性问题,目前未知 - 粘贴html
浏览器间的行为差异很大,因此需要对此进行一致性处理,主要问题表现在标签结构和style属性上,如何处理inEdit还没有确定,CKEditor 和 UEditor对标签结构处理的很好,但是在 chrome下style没有进行很好的处理 - 原生execCommand
这其实包括了所有的操作,加粗,颜色,列表,缩进,所有这些其实浏览器间都不兼容,如果要兼容需要重写代码实现这些功能,这衍生出了下面的问题 - 节点分割
因原生execCommand的问题,需要对节点进行分割 - fake对象
fake对象就是伪对象,在编辑期插入一个视频,为了操作的方便通常都通过一个fakeImg来实现,UEditor,CKEditor对fake对象都采用了,用在属性上嵌入html代码的方法,UEditor对一些baidu的产品,比如百度地图的伪对象进行了特殊处理,inEdit 预期对fake进行非嵌入html代码的处理 - 表格,图片
浏览器中兼容性差异巨大,需要特殊处理,表格的高级特性更是需要大量的代码处理 - 禁止从外部拖拽
- 右键菜单必须被处理
好的解决方案
- 对话框
UEditor把对话框作为独立的html用iframe的方式是很佳的方案 - 截获粘贴
UEditor plugins/paste/paste.js 的解决方案非常优秀 - html解析
UEditor和CKEditor都有自己的html解析,inEditor计划采用 simplehtmlparser
有BUG无法用,采取UEditor的吧 - 事件模型
这个就是api里面的addEvent,fire这些操作
inEdit计划采用的一些方案
- 继续采用 contenteditable="true"
这也是为什么写 inEdit 的原因,不然inEdit就没有存在的意义了 - 样式模块
inEdit 把样式的操作独立出来,作为基础模块供需求使用 - 单个引用文件,动态加载需求文件
这个不但在开发期还是部署,都会提供一些方便,而且和完全打包是兼容的 - 所有功能都采用 plugin 模式,取消原生execCommand,完全用节点操作完成(delete问题待定)
原因如上述 - 暂时借助jQuery
为了提高开发速度,对于DOM的操作借助jQuery,当稳定以后可以考虑设计独立的模块替代相关功能
目前的开发进度,事件模型、基础框架、fake对象已经成型,进入替代原始execCommand阶段,inEditor要被重构了
=============================================
2011.8.31
对w3c的html定义要完全过一遍了,零零碎碎太多,又是上下文,有所内容模型的,一个个来吧,先做内容模型定义,这就是个dtd了,开发成本太高了。没办法,发现其他版本的dtd定义都不够仔细,而且为了适应编辑器的需求,有必要对w3c的定义做些细微调整,以便简化操作
2011.11.01
发现mercury已经实现了,考虑直接采用mercury
2011.8.30
遇到太多失败,都不确定是否能完成了
上一篇: Android如何分析排查ANR
下一篇: Android如何解决ANR