javascript - 使用 "span"元素创建基于 Web 的自定义文本编辑器——一个坏主意？

Question

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

所以我一直在尝试各种方法来实现自定义文本编辑器。我的第一种方法是检测插入符号插入的鼠标点击(尽管没有可见的插入符号，因为似乎没有办法实现这一点)。这工作得相当好，但不幸的是没有办法显示插入符(又名闪烁的工字梁)。

这意味着我的闪烁插入符号也必须是定制的。我只能想到两种以兼容所有浏览器的方式实现这一目标的好方法。

1. 第一个(可能更好)的选择是在 JavaScript 中实现自定义布局引擎，就像 Google 对 Google Docs 所做的那样。

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

所以我的问题是，选项 #2 真的是个坏主意吗？如果是，为什么？

Answer 1

首先 - 您真的需要使用自己的编辑器吗？有Firepad和 Etherpad他们非常酷的协作编辑，也许还有更多不基于 contenteditable 的开源编辑器。创建这样的编辑器真的很难，所以在上面浪费时间是没有意义的。

但是，如果您真的想开发自己的解决方案并且需要在所有浏览器上完全相同的行为，那么您注定要失败 ;)。即使您会避免 contenteditable，也肯定有其他地方可能出错。

无论如何，答案:

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

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