一开始我应该提到我是一个CKEditor核心开发人员,因此我的意见可能并不完全客观:)。
HTML 编辑 AFAIK 的状态在过去几年没有改变。浏览器供应商几乎没有花时间修复错误 - 时间如此之少,以至于CKEditor trac上由浏览器问题引起的大多数最古老的错误仍然有效,而且我们创建的大多数 hack 仍然需要。我不仅仅指我们仍然支持的 IE 7 或 8,因为事实上 IE 可能不是最差的。我没有准确地检查过,但我认为由于最近 IE 版本中对 DOM API 的全面改进,它们可能比其他浏览器需要更少的 hack,因为它的编辑支持似乎是最稳定和最完整的。例如,Webkit 浏览器需要最丑陋的 hack(请参阅:Webkit 错误和已关闭的 CKEditor 票证),这个错误已有5 年历史. 更重要的是 - 这不是边缘情况或不太可能的情况 - 这个问题使得创建整个选择范围成为不可能 - 例如在空的内联元素 IIRC 内。
因此,与一般的 Web 技术不同,HTML 编辑站在 10 年前的位置。相同的错误,相同的缺失功能,相同的...标记。猜猜这个fontName
命令创建了什么?<font face="">
- 是的,不是开玩笑。至少浏览器在这里非常一致......但是一致性很快就消失了。
规格呢?有一个草案,但它根本没有帮助 - 它只是标准化当前状态,我们知道这看起来不太好。和 AFAICS,草案已经死了。
还有一件事让我担心——剪辑的方向。Googlecontenteditable
在 Gmail 中使用(不,Google Docs 不是基于contenteditable
),所以它不关心 HTML 输出。Apple 在他们的 iOS 电子邮件应用程序和 MacOS 邮件应用程序中重用了 HTML 编辑组件(因为我看到了相同的特定行为)。Mozilla 在 Thunderbird 中重用 Gecko,如果 Microsoft 在 Outlook 中也这样做,我不会感到惊讶。他们都不关心 HTML 输出。这些引擎是用来理解每一个废话而不是修复它,而 HTML 编辑草案就是关于它的。
多亏了这一切,我们才能看到像这样的新问题。在Blink/Webkit 错误报告中,我总结了按下退格键时所有不正确的结果(来自我们的 POV - 关心 HTML 的开发人员)。它被设计成看起来不错(虽然它不是),但 HTML 和编辑 API 并不重要。
我不在乎这个。我需要一个编辑器!
所有这些的解决方案是在浏览器之后修复所有内容和/或用我们自己的替换它们的本机实现。在过去的 1.5 年里,我几乎一直致力于过滤和规范化输入和输出。在 CKEditor 4.0 中,我们重写了整个粘贴和 HTML 插入过程,在最近发布的 CKEditor 4.1 中,我们引入了高级内容过滤器,它使输入数据适应编辑器配置。因此,启用的功能越少,HTML 中允许的功能就越少。检查此示例- 尝试粘贴/编写/创建糟糕的 HTML。
当然,还有改进的余地。例如,我们无法在编辑期间立即过滤数据。如果浏览器(如 Webkit)造成混乱,我们可以在输出上修复它,但实际上我们还没有决定这样做,因为过滤是一个非常复杂的过程并且可能会破坏性能。我们限制输入和用户操作,因此有一天我们将实现自己的退格/删除处理程序,以防止浏览器弄乱我们的 HTML。这是唯一的解决方案,这就是为什么只有 2 或 3 个优秀的所见即所得编辑器的原因。
无论如何,浏览器的 HTML 编辑实现几乎没有任何变化,但所见即所得的编辑器世界发生了很大变化。如果您根据几年前的经验,我建议您再次检查它们。