所见即所得编辑器 inEdit 开发笔记(发现 mercury,考虑直接使用)
冀翰翮
经过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
遇到太多失败，都不确定是否能完成了
类似资料：