冰山一角

关于本系列文章

计划暂时是这样，首先介绍一些历史、知识背景，然后详细分析现状和需求，开始设计一个可扩展，低耦合的编辑器，最后针对一些难点问题进行单个分析。

历史、现状

起初，世界上的浏览器本没有编辑器功能。到了IE4.0 (1997年)，微软提供了document.selection，利用这个对象，前端开发人员可以让一个iframe进入编辑状态，里面可以输入富文本内容，并且能通过程序添加复杂的编辑操作。那个时候还没有W3C的相关规范，这个selection对象以及两种选区类型（textRange和controlRange）都是微软自己实现的。

三年后，有了W3C的相关规范(2000年)，这个规范和IE的实现完全不同，firefox等一干浏览器陆续根据规范实现了自己的selection和Range对象。

前端工程师的悲剧就这样酿成了，有两套截然不同的方式来处理选区(selection)，不仅仅如此，对execCommand()方法的支持也大相径庭，一个相同的命令在不同的浏览器下执行会出现不同的效果。最要命的，浏览器还经常会有一些诡异的问题，比如在某些时候对选区的不当操作会导致IE直接崩溃等。

但是在线编辑器的使用场景相当广泛：写blog、论坛发帖、淘宝卖东西、在线聊天等应用场景都需要使用编辑器，他们对编辑器的要求各不相同。编辑器已经成为了一个基础件，几乎所有的互联网公司都需要用到。

后来出现了一些开源编辑器，比较出名的有：ckeditor（原来叫fckeditor）， tinymce，eWebEditor等，最近，淘宝也开源了他们的kissy编辑器（功能尚不完善）。但是开源编辑器都各有不足，ckeditor足够强大，重写了浏览器的所有操作。但是模块之间的耦合性很高（3.0有所改善，但仍然不够），体积过于庞大，其他的一些编辑器则要么bug太多，功能不全，要么不方便二次开发。另外，一些对编辑器要求很高的服务，像zoho、Google docs等等，都带有一个很强大的编辑器。

目标

一个优秀的编辑器，首先要尽量解决浏览器之间的差异，在不同的浏览器下表现一致。

另外，为了让编辑器在各种不同环境下适应不同的需求，尤其是二次开发的需求，这个编辑器还应该是“通用”、“可扩展”、“低耦合”的。

具体的设计思路在后面我会专门撰文说明，首先的这几篇文章，是让一些没有接触过编辑器开发的童鞋了解一些基础知识。

本文是在线编辑器系列文章的第一篇，在这个系列文章中，我会逐步深入和大家分享编辑器开发过程中的奥妙和各种奇怪的问题。下一篇文章将介绍如何拥有一个可编辑区域，如果你对我的文章感兴趣，欢迎从页面右边订阅我的博客及时收到更新。