内容可编辑文本编辑器

Question

我已经尝试了几个HTML编辑器,包括TinyMCE,CKEditor和现在的NicEdit.NicEdit在一个方面很好 - 它很容易定制.但是,我发现它们都有产生非常差的HTML的倾向.不一定是这样,但是因为他们没有做很多工作来正确解释无效的用户操作,例如在没有先做出选择的情况下尝试设置某些内容.

最终使用包含类似内容的HTML非常容易

<span style='color:#ff0000'><span style='color:#ff0000'><span style='color:#ff0000'>Red</span></span></span>

我是否正确地认为这几乎是内容可编辑概念的限制？如果目的是电子邮件或在诸如此类的论坛上发布帖子,那么糟糕的HTML并不重要,但如果生成的HTML必须在网页的上下文中使用,那么生活得相当不舒服.如果所有这些都是对的,那么替代方案是什么？也许是一个基于Flash的插件编辑器,可以生成更好的HTML并且更难以解释用户想要做什么？

我认为原则上可以研究生成的输出并在必要时清除六角形的跨度,但这可能是一项艰巨的任务.

Answer 1

一开始我应该提到我是CKEditor核心开发人员,因此我的观点可能不完全客观:).

HTML编辑AFAIK的状态在过去几年中没有改变.浏览器供应商几乎没有花时间修复错误 - 因此,由浏览器问题引起的CKEditor trac上大多数最老的错误仍然有效,而且我们创建的大多数黑客仍然是必需的.我不仅仅意味着我们仍然支持IE 7或8,因为实际上IE可能不是最差的.我没有准确地检查过,但我认为,由于最近IE版本中DOM API的一般改进,它们可能比其他浏览器需要更少的黑客,因为它的编辑支持似乎是最稳定和完整的.例如,Webkit浏览器需要最丑陋的hack(参见:Webkit bug和关闭的CKEditor票证),这个bug已经有5年了.更重要的是 - 这不是边缘情况或不太可能的情况 - 这个问题使得无法创建整个范围的选择 - 例如在空的内联元素IIRC内.

因此,与一般的网络技术不同,HTML编辑站在10年前的位置.相同的错误,相同的缺失功能,相同的...标记.猜猜fontName命令创造了什么？<font face=""> - 是的,不是在开玩笑.至少浏览器在这里非常一致......但是一致性很快消失了.

规格怎么样？有一个草案,但它根本没有帮助 - 它只是标准化当前状态,我们知道这看起来不太好.而AFAICS,草案已经死了.

还有一件让我担心的事情 - 编辑的方向.Google contenteditable在Gmail中使用(不,Google Docs不是基于此构建的contenteditable),因此它不关心HTML输出.Apple在他们的iOS电子邮件应用程序中重用HTML编辑组件,也许在Mail for MacOS中重复使用(因为我看到了相同的特定行为).Mozilla在Thunderbird中重用了Gecko,如果微软在Outlook中做同样的事情,我也不会感到惊讶.所有这些都不关心HTML输出.这些引擎用于理解每个垃圾而不是修复它,HTML编辑草案就是它的全部内容.

多亏了这一切,我们可以看到像这样的新问题.在Blink/Webkit错误报告中,我在按退格键时总结了整个范围的错误(来自我们的POV - 关心HTML的开发人员).它看起来很漂亮(尽管它没有),但HTML和编辑API并不重要.

我不在乎这个.我需要一个编辑!

所有这些的解决方案是在浏览器之后修复所有内容和/或用我们自己的替换它们的本机实现.在过去的1.5年里,我几乎专注于过滤和规范化输入和输出.在CKEditor 4.0中,我们重写了整个粘贴和HTML插入过程,在最近发布的CKEditor 4.1中,我们引入了高级内容过滤器,它将输入数据调整为编辑器配置.因此,启用的功能越少,HTML中允许的功能就越少.检查此示例 - 尝试粘贴/编写/创建糟糕的HTML.

当然,还有改进的余地.例如,我们无法在编辑过程中立即过滤数据.如果浏览器(如Webkit)造成混乱,我们可以在输出上修复它,但实际上我们还没有决定这样做,因为过滤是一个非常复杂的过程,可能破坏性能.我们限制输入和用户操作,因此有一天我们将实现自己的退格/删除处理程序,以防止浏览器弄乱我们的HTML.这是唯一的解决方案,这就是为什么只有2或3个好的WYSIWYG编辑器.

无论如何,浏览器的HTML编辑实现几乎没有任何变化,但在WYSIWYG编辑器世界中已经发生了很多变化.如果您根据几年前的经验,我建议您再次检查它们.