所见即所得编辑器 inEdit 开发笔记(发现 mercury,考虑直接使用)

冀翰翮
2023-12-01

经过2年时间的沉寂,inEdit 又开始进行开发了,上一次停止开发,主要原因是


 

  1. 工作了,没时间开发,现在失业中,终于又有时间了
  2. 问题太多,没有找到好的解决方案


最近通过学习 CKEditorUEditor 获得了一些思路,整理如下

主要兼容性问题

 

  1. range
    也就是选择区域范围问题,必须处理成一致的接口和对边界进行处理,对于IE可以考虑使用 ierange
    但是 ierange 有个BUG需要注意,在某些场景下获取 range text会出错
    BUG更多无法用,采取UEditor的吧

  2. 回车
    各个浏览器中差异很大,为了得到一致性有必要截获回车事件并通过代码来处理回车
    问题衍生,如果选择了某个区域,那其实要先做删除处理,这个问题 UEditor 采用自己的代码完成
    inEdit目前暂时使用 document.execCommand('delete',false,null); 解决,是否会造成一致性问题,目前未知

  3. 粘贴html
    浏览器间的行为差异很大,因此需要对此进行一致性处理,主要问题表现在标签结构和style属性上,如何处理inEdit还没有确定,CKEditor 和 UEditor对标签结构处理的很好,但是在 chrome下style没有进行很好的处理

  4. 原生execCommand
    这其实包括了所有的操作,加粗,颜色,列表,缩进,所有这些其实浏览器间都不兼容,如果要兼容需要重写代码实现这些功能,这衍生出了下面的问题

  5. 节点分割
    因原生execCommand的问题,需要对节点进行分割

  6. fake对象
    fake对象就是伪对象,在编辑期插入一个视频,为了操作的方便通常都通过一个fakeImg来实现,UEditor,CKEditor对fake对象都采用了,用在属性上嵌入html代码的方法,UEditor对一些baidu的产品,比如百度地图的伪对象进行了特殊处理,inEdit 预期对fake进行非嵌入html代码的处理

  7. 表格,图片
    浏览器中兼容性差异巨大,需要特殊处理,表格的高级特性更是需要大量的代码处理

  8. 禁止从外部拖拽

  9. 右键菜单必须被处理
好的解决方案
  1. 对话框
    UEditor把对话框作为独立的html用iframe的方式是很佳的方案

  2. 截获粘贴
    UEditor plugins/paste/paste.js 的解决方案非常优秀

  3. html解析
    UEditor和CKEditor都有自己的html解析,inEditor计划采用 simplehtmlparser
    有BUG无法用,采取UEditor的吧

  4. 事件模型
    这个就是api里面的addEvent,fire这些操作
inEdit计划采用的一些方案
  1. 继续采用 contenteditable="true"
    这也是为什么写 inEdit 的原因,不然inEdit就没有存在的意义了

  2. 样式模块
    inEdit 把样式的操作独立出来,作为基础模块供需求使用

  3. 单个引用文件,动态加载需求文件
    这个不但在开发期还是部署,都会提供一些方便,而且和完全打包是兼容的

  4. 所有功能都采用 plugin 模式,取消原生execCommand,完全用节点操作完成(delete问题待定)
    原因如上述

  5. 暂时借助jQuery
    为了提高开发速度,对于DOM的操作借助jQuery,当稳定以后可以考虑设计独立的模块替代相关功能

目前的开发进度,事件模型、基础框架、fake对象已经成型,进入替代原始execCommand阶段,inEditor要被重构了


=============================================
2011.8.31
对w3c的html定义要完全过一遍了,零零碎碎太多,又是上下文,有所内容模型的,一个个来吧,先做内容模型定义,这就是个dtd了,开发成本太高了。没办法,发现其他版本的dtd定义都不够仔细,而且为了适应编辑器的需求,有必要对w3c的定义做些细微调整,以便简化操作

2011.11.01
发现mercury已经实现了,考虑直接采用mercury
2011.8.30
遇到太多失败,都不确定是否能完成了


 类似资料: