使用“span”元素创建基于Web的自定义文本编辑器 - 一个坏主意?

时间:2013-05-26 16:25:25

标签: javascript html performance wysiwyg

我对Web应用程序有一个想法,我需要完全控制嵌入式文本编辑器的功能,文本编辑器必须在所有浏览器中完全运行。在这种情况下,标准的contenteditable功能还不足以满足我的需求。

所以我一直在尝试各种方法来实现自定义文本编辑器。我的第一个方法是检测插入插入符号的鼠标点击(虽然没有可见的插入符号,因为似乎没有办法实现这一点)。这很好用,但不幸的是没有办法显示插入符(也就是闪烁的工字梁)。

这意味着我的闪光插入符也必须定制。我只能想出两种很好的方法来实现这一点,这种方式将在所有浏览器中兼容。

  1. 第一个(可能更好)选项是在JavaScript中实现自定义布局引擎,就像Google使用Google Docs一样。

  2. 第二个解决方案(可能更容易)将每个字符封装在自己的<span>元素中,从而允许将特殊插入符号放在特定字符之间。这确实意味着会有很多span元素,但这肯定会在利用浏览器布局引擎的同时实现我所需要的。这种方法的另一个好处是我不需要依赖狡猾的浏览器特定的文本选择黑客。

  3. 所以我的问题,选项#2是一个非常糟糕的主意吗?如果是这样,为什么?

1 个答案:

答案 0 :(得分:5)

首先 - 你真的需要在你自己的编辑器上工作吗? FirepadEtherpad有非常酷的协作编辑,可能还有更多不基于contenteditable的开源编辑器。创建这样的编辑器真的很难,所以浪费时间就没有意义了。

但是,如果您真的想要使用自己的解决方案,并且在所有浏览器中需要完全相同的行为,那么您将注定失败;)。即使你会避免contenteditable,肯定还有其他可能出错的事情。

无论如何,答案是:

  1. 第一个选项在开始时非常困难且耗时,但它比第二个选项提供更多功能。例如。拥有完全自定义的布局引擎,您将能够实现分页符而无需等待CSS3的实现(您永远不会依赖它,因为您希望完全在所有浏览器中具有相同的行为)。事实上,您将能够绕过大多数浏览器的渲染差异。但是,除非你有一个体面的JS开发团队和几个月(至少),我甚至不会开始考虑这个。

  2. 第二种解决方案 - 重用DOM更加真实。我会首先执行一些性能测试,但是每个字符的跨度很容易找到鼠标单击后插入符号的位置。没有它,它需要一些技巧......我不知道。您可以尝试检查Etherpad和Firepad(使用Ace code editor)如何处理它,但仍然 - 包装将是最简单的选择,至少在不错的浏览器上它不应该导致性能问题,除非你想真正编辑长文档(但随后你可以开始一些优化)。