可视化编辑器的开发心得

到现在为止专心开发KindEditor积累了一些经验，想和大家分享一下编辑器开发心得，希望越来越多的开发者加入到编辑器开发队伍里。

1. 测试环境
开发基于浏览器的编辑器最痛苦的事情是解决各浏览器的兼容性，刚开始每次添加功能或修改功能IE6到8、Firefox2和3、Safari、Chrome、Opera都测试一遍，后来总结出来经验，只测试IE8、Firefox 3、Chrome，最后发布前再测试其它浏览器。
IE 6、7、8：DOM操作方面基本都一样，UI方面需要注意quirks mode(怪异模式)和strict mode(严格格式)，用IE8自带的开发人员工具（按F12就出来）可以修改成怪异模式。
Firefox 2、3：区别还是蛮大的，主要碰到的问题是创建iframe文档的时间点不一样，Firefox 2上创建iframe文档后不能马上操作iframe的DOM，用setTimeout延迟操作就没问题。
Chrome和Safari：因为都用Webkit，Chrome没问题的话Safari也没问题。
Opera：支持可视化最烂，而且每次升级很不稳定，记得10 beta版本根本不能使用9上面正常运行的编辑器。现在支持Opera的原则是能使用就可以，不再研究细节问题了。

2. execCommand和range
开发可视化编辑器最重要的接口是execCommand，现在大多数编辑器或多或少都依赖这个函数，轻量级编辑器绝大多数功能都要依靠它。execCommand最初IE上实现，后来其它浏览器也陆续支持execCommand。execCommand虽然很优秀，但每个浏览器生成不同的HTML代码，很难控制最后输出结果，最新的ckeditor基本完全不用execCommand了。
弥补execCommand缺点的技术是range和selection。range是一个HTML的范围，并提供一些方法来操作HTML范围，比如删除、复制、提取一段HTML。
IE和其它非IE浏览器range接口完全不同，如果range操作比较多的话最好自己写一个统一的类库。IE的range是基于文本和控件的（textRange和controlRange），非IE的range是W3C规范里的range，有开始节点和结束节点的位置，可以精确的操作DOM，下面是W3C range的使用例子。

<p><strong>[粗体</strong>]内容<img src="" /></p>

开始节点：textNode - 粗体
开始位置：0
结束节点：textNode - 内容
结束位置：0

<p><strong>粗体</strong>内容[<img src="" />]</p>

开始节点：textNode - 内容
开始位置：2
结束节点：p node （因为img node后面没有textNode，所以只能用父节点的子节点位置来描述。）
结束位置：3

3. 后退/撤销
开发编辑器还有一个要解决的问题是undo/redo，在IE上iframe的undo记录和外部document的undo记录是在一起的，任何一个对外部document的变更会失去undo记录。
目前KindEditor用最原始的全文保存方法，每次修改内容时把html保存到一个数组里，这么做代码非常简单，但无法保存选中状态，我目前还没找到合适的解决方案。

4. 删除格式
execCommand有一个removeformat命令，这个命令在IE上有一个缺陷，就是不能删除span。要解决这个问题只能自己实现这个功能，原理是先切割选中范围的开始节点和结束节点，然后遍历node删除中间的样式标签。

5. URL格式
在IE上相对路径自动变成包括域名的绝对路径，如果用户需要将测试环境的数据导入到正式环境就有问题了。解决方法是根据location.host正则匹配重新修改成相对路径。
2009-12-23补充：更好的方法是把URL保存在自定义属性里，比如<img my_src="test.gif" src="test.gif" />，最后输出时用my_src重置src，这样可以做到输入什么显示什么的效果。

侬终于开始了……

一直想问问你，关于我的as做bar，js控制iframe的想法，你决定具体上可行吗？

bar是指toolbar吗？UI用flash，编辑区域用iframe应该可行的。

KindEditor要是支持table的自定义就好了。这样可以做自定义表单了。之前扩展了KindEditor。推荐给公司的OA组用做编辑器。最后他们换了FCK。主要是因为在COPY WORD内容时速度非常慢

可不可以把js做成for IE ,for FF....不同的浏览器不同的包呢
用后台判断出到底是什么类型的浏览器，再进行加载
这样可以减少js大小，把罗里罗嗦的判断代码去掉

嗯，这个不错，google 的就是这样搞的

那么它是用什么？

因为在iframe里的文档也是document，和普通的document操作一样，用range,node就可以修改任何HTML。

听上去似乎有点像jindw说的“局部刷新”，根据操作重新生成这一块儿的html。

那么性能如何呢？尤其在富文本量过大的情况？