在制作富文本/所见即所得编辑器时,Contenteditable div与iframe

tim*_*son 28 javascript jquery wysiwyg contenteditable execcommand

我正在尝试权衡使用<div><iframe>制作我自己的富文本/所见即所得编辑器的优点和缺点.

在这样做的时候,为什么我不能只使用一个满足 <div>而且为什么这么多人更喜欢<iframe>

背景讨论:根据我的理解,制作一个所见即所得编辑器的常用方法是使div或iframe 满足,然后对execCommand包含div或iframe主体的文档进行操作,使其文本变为粗体或其他.

这是HTML:

<html><!--parent doc-->
  <body><button type="button" class="btn-bold">Bold</button>
       <div contenteditable="true"></div>
  </body>
</html>
Run Code Online (Sandbox Code Playgroud)

VS:

<html><!--parent doc-->
  <body><button type="button" class="btn-bold">Bold</button>
    <iframe>
       <body contenteditable="true"></body>
    </iframe>
  </body>
</html>
Run Code Online (Sandbox Code Playgroud)

和JS:

$(document.body).on('click', '.btn-bold', function(){
     document.execCommand('bold', false, null); 
});
Run Code Online (Sandbox Code Playgroud)

VS:

$(document.body).on('click', '.btn-bold', function(){
     window.frames[0].document.body.execCommand('bold', false, null); 
});
Run Code Online (Sandbox Code Playgroud)

看起来大多数制作精良的富文本编辑器都使用iframe.虽然我可以很容易地在Webkit浏览器中使用这个contenteditable/execCommandcombo来处理div/iframe,但是我有一个地狱般的时间试图让iframe在Firefox中运行.我不得不求助于将脚本和样式表加载到iframe和各种废话中来复制我可以使用基于div的版本轻松完成的任务.所以<div>基于方法似乎更可取.我重新考虑任何有力的理由?

Rei*_*mar 30

首先......如果您正在考虑商业用途,请不要尝试制作自己的WYSIWYG编辑器.对于个人项目来说这是一个很酷的主意,因为你可以学到很多东西,但是你需要花费数年时间来创建编辑器,你可以将它卖给关心它的人是否真的有效,而不仅仅是外观.我最近看到一些看起来很酷的新编辑,但它们真的不起作用.真.这不是因为他们的开发人员很糟糕 - 这是因为浏览器很糟糕.

好的,这是一个很棒的介绍,现在有些事实:

  1. 我是CKEditor的开发人员之一.
  2. 它已经开发了大约10年.
  3. 我们的Trac仍有大约1千个活跃问题.
  4. 我们不喜欢网络开发:P.

现在的答案 - 除了Tim Down在这里写的构建一个所见即所得的编辑器,你可以阅读我在这个问题下所写的内容HTML WYSIWYG编辑器:为什么可编辑内容在iFrame中移动

基本上,在iframe中你更安全,你有整个文档,内容不会从你的可编辑元素中泄漏,你可以使用样式等.iframe方法也有一些缺点 - 它更重,引导代码是......真的很棘手,你不能继承编辑所附网站的风格,我想在这种情况下管理焦点可能会更加困难,你必须注意你正在创建新元素的文档(仅与IE <8相关.

请记住 - 除非你为这样的问题做好准备,否则不要编写自己的编辑器.粘贴为纯文本Contenteditable div&textarea(word/excel ...):D


小智 17

原因 iframe

优点

  1. CSS隔离
  2. 安全隔离(我无法详细说明这一点,我重复我读到的内容)

缺点

  1. 更重(但不是重要/明显的一点)
  2. 更难以从JavaScript访问.

就个人而言,我开发了自己的编辑器,我选择将其放入iframe.