首先我应该提到,我是CKEditor核心开发人员,因此我的意见可能不完全客观 :).
据我所知,HTML编辑的状态在过去几年中没有改变。浏览器厂商花费的时间修复错误很少,以至于
CKEditor trac上由浏览器问题引起的大多数最古老的错误仍然有效,我们创建的大部分hack仍然需要使用。我指的不仅是IE 7或8,因为实际上IE可能并不是最糟糕的。我没有精确检查过,但我认为由于近期IE版本中DOM API的一般改进,它们可能需要比其他浏览器更少的hack,因为它的编辑支持似乎是最稳定和完整的。例如,对于Webkit浏览器需要最丑陋的hack(参见:
Webkit bug和
closed CKEditor ticket),而这个bug已经有
5年了。更重要的是,这不是边缘案例或不太可能发生的情况——这个问题使得创建整个选择范围变得不可能,例如在空内联元素中。
因此,与一般的网络技术不同,HTML编辑停留在10年前的状态。相同的错误、相同的缺失功能、相同的标记语言。猜猜
fontName
命令创建了什么?没错,不是开玩笑,是
<font face="">
。至少浏览器在这方面非常一致...但一致性很快就消失了。
那规范呢?有一个
draft,但它根本没有帮助——它只是将当前状态标准化,而我们知道当前状态并不好。据我所知,这个草案已经死了。
我还有一个担心,那就是编辑方向。谷歌在Gmail中使用
contenteditable
(不,Google Docs并非基于
contenteditable
构建),因此它不关心HTML输出。苹果在iOS的电子邮件应用程序以及可能在MacOS的Mail中重复使用HTML编辑组件(因为我看到相同的特定行为)。Mozilla在Thunderbird中重用Gecko,如果微软在Outlook中也这样做,那也不足为奇。所有这些公司都不关心HTML输出。这些引擎被设计成理解每一种“垃圾”,而不是修复它,而HTML编辑草案正是关于这个问题。
由于所有这些,我们可以看到像
这个这样的
新问题。在
Blink/Webkit bug report中,我总结了按下退格键时出现的整个不正确范围(从我们关心HTML的开发人员的角度来看)。它被设计得很漂亮(尽管并不是),但HTML和编辑API并不重要。
我不关心这个。我需要一个编辑器!
解决所有这些问题的方法是在浏览器之后修复所有内容并/或用我们自己的实现替换它们的本机实现。在过去的1.5年里,我几乎完全致力于过滤和规范化输入和输出。在CKEditor 4.0中,我们重写了整个粘贴和HTML插入过程,在最近发布的CKEditor 4.1中,我们引入了
高级内容过滤器,该过滤器可以将输入数据适应编辑器配置。因此,启用的功能越少,HTML允许的内容就越少。请查看
此示例-尝试粘贴/编写/创建垃圾HTML。
当然,仍有改进的空间。例如,我们无法立即在编辑期间过滤数据。如果浏览器(如Webkit)创建了一堆麻烦,我们可以在输出时进行修复,但实际上我们还没有决定这样做,因为过滤是一个非常复杂的过程,可能会破坏性能。我们限制输入和用户操作,因此有一天我们将实现自己的退格/删除处理程序,以防止浏览器破坏我们的HTML。这是唯一的解决方案,这就是为什么只有2或3个好的所见即所得编辑器的原因。
无论如何,在浏览器的HTML编辑实现方面几乎没有什么变化,但所见即所得编辑器的世界发生了很多变化。如果你是基于几年前的经验进行操作,我建议你再次检查它们。