【问题标题】:The State of contenteditable可编辑的状态
【发布时间】:2010-07-30 20:18:05
【问题描述】:

contenteditable 的状态

所见即所得编辑器生成的标记非常糟糕。它充满了样式属性,通常甚至不是有效的 HTML(缺少结束标签、重叠样式等)。对于contenteditable 引入的问题,是否有任何既定的解决方案?如果没有,我该如何创建一个?

无效的 HTML

例如,在一个流行的富文本编辑器中输入一个无序列表和一行文本后,我会看到以下 HTML:

<ul><li>foo</li><li>bar</li></ul><div>baz

div 标签从何而来?为什么不关门?为什么不是一个段落——当然是正确关闭的?这可以预防吗?

非语义 HTML

另一位编辑制作了以下内容:

<p style="font-size:11pt; line-height:115%; margin:0pt 0pt 0pt 36pt; text-indent:-18pt"><span style="color:#000000; font-family:Arial; font-size:11pt; font-style:normal; font-weight:normal; text-decoration:none">●</span><span style="font:7.0pt &#39;Times New Roman&#39;">     </span><span style="color:#000000; font-family:Arial; font-size:11pt; font-style:normal; font-weight:normal; text-decoration:none">Lorem</span></p><p style="font-size:11pt; line-height:115%; margin:0pt 0pt 0pt 36pt; text-indent:-18pt"><span style="color:#000000; font-family:Arial; font-size:11pt; font-style:normal; font-weight:normal; text-decoration:none">●</span><span style="font:7.0pt &#39;Times New Roman&#39;">     </span><span style="color:#000000; font-family:Arial; font-size:11pt; font-style:normal; font-weight:normal; text-decoration:none">ipsum</span></p>

这是有效的标记,但它在语义上很糟糕!编辑器插入了 literal 项目符号字符,而不是样式化的无序列表。作为开发人员,我不知道如何处理 contenteditable 生成的标记。就造型而言,它完全没用。

换人

直到最近,我一直在使用 Markdown 作为从用户那里生成语义正确的 HTML 的工具。但是,Markdown 缺少我的用户所要求的某些功能(非技术人员的易用性、图像定位等)。在寻找一个可以生成有效的语义标记数周的所见即所得编辑器之后,我发现contenteditable 使这变得不可能。有人在谈论这些问题的解决方案吗?我该如何参与。

[更新]澄清

我想我之前并没有完全清楚。我不是在寻求解决contenteditable 问题的方法。我找到了很多,包括下面提到的大部分。我试图找到的是这些问题的根本原因。为什么contenteditable 这么坏?是因为技术问题还是遗留代码问题?此外,正在采取什么措施来修复它?这项工作在哪里进行?

[更新]谷歌文档

上面第二个示例中的 HTML 来自 Google 文档编辑器。但是,正如AlfonsoML 在下面指出的那样,Google 文档在其编辑器中不使用contenteditable。他们的技术在here进行了解释。

【问题讨论】:

    标签: javascript html css wysiwyg contenteditable


    【解决方案1】:

    我怀疑它的状态有几个特定的​​原因:

    1.) 定义它的 HTML5 标准没有定义它应该输出什么,让每个实现自己决定。

    2.) 编辑器不知道您是想要准确的表示还是语义表示。这些通常是取舍。

    3.) 看起来 Mozilla 将其旧的 Netscape Mail/Composer 代码拖入其 designMode 实现,然后将其拖入 contentEditable。它仍然使用与 10 年前相同的虚线轮廓和小红色手柄,我怀疑有大量遗留代码。

    4.) 看起来 Internet Explorer 的做法几乎相同,而 IE 从一开始就没有做任何正确的事情。它仍然以怪癖和“兼容性”模式的形式拖着它的遗产。

    5.) 它实际上只用于 CMS 系统和论坛/评论框,并且通常这些在实现方面有相当重的包装。我在其他地方没有看到太多用法,尤其是“准系统”。

    6.) 成功的在线文字处理器很少,所见即所得或页面布局应用程序也更少。创建准确的编辑器的压力不存在。更糟糕的是,Microsoft 销售 Word 和 Expressions 等离线软件,这些软件肯定会受到在线编辑器增长的损害,尤其是高质量的免费软件。

    7.) Microsoft 拥有创建生成无效和臃肿 HTML 代码的工具的传统,这些工具今天仍然存在于 Outlook 2010 和 Office 套件中。

    8.) 有时,相同的选择和编辑命令可能适用于占用相同空间的多个可能对象,而编辑器永远无法真正知道您要更改哪个对象。此外,编辑命令可能会导致元素以未定义或意外的方式拆分(同样,它不知道您更喜欢哪种方式)。

    我不相信 contentEditable 会像剪切您自己的 HTML 或使用专用工具一样好。我只是专注于在结果上运行一些基本的 cruft/repair 工具(如 HTMLTidy)并收工。

    【讨论】:

      【解决方案2】:

      这是一个困难的问题,每个人解决的方式都不同。

      我知道以下可能性:
      * 放手吧(最糟糕的)
      * 尝试自己修复 HTML(TinyMCE 和 CKEditor 尝试以不同的成功率进行修复)
      * 使用像 XStandard 这样的插件
      * 使用 DOM tom 制作您自己的编辑器 - 用 DIV 制作插入符号,自己处理选择、编辑和一切。例如,这就是谷歌的做法。不过,这需要大量编码。

      【讨论】:

      • 感谢您的回答。我从未听说过 XStandard,但我一定会去看看。至于制作你自己的编辑器,上面的第二个例子来自谷歌文档——尽管他们的编辑器很好,但它吐出的内容却是可笑的。
      【解决方案3】:

      对于支持contenteditable 的浏览器,可以很容易地找到解决方案;使用例如jQuery to save the data,并将新元素附加到可编辑内容(显然是带有按钮)上,您可以轻松获得一个简单的所见即所得编辑器。

      一个可能更难解决的问题是确保这些新元素的放置是正确的。但是,这个has been solved for Webkit,我相信在其他浏览器中也可以做到。

      使用contenteditable 的编辑器既易于部署又轻量级,这绝对是值得开发的东西,恕我直言。

      编辑:重新阅读您的问题后,我意识到您实际上正在寻找一个有效的非contenteditable 解决方案。我不知道为什么; AFAIK contenteditable 产生有效的标记,如果你完全控制(只允许用户通过你的 UI 插入元素和更改它们的属性),它也将是语义的。 AFAIK 目前没有所见即所得编辑器使用contenteditable,但我可能是错的。

      【讨论】:

      • 我同意,但我如何确保编辑器输出的内容有效且符合语义?
      • 不应该需要确保它是有效的,尽管可以在保存时验证它并在它无效时返回一个错误。在一定程度上,语义可以通过强制用户使用你的 UI 来确保。它不会阻止用户从段落之类的列表中列出,但是在保存之前可以很容易地“修复”类似的东西(假设用户遵守合理的“标准”,例如使用* 来表示列表)。
      【解决方案4】:

      我认为您的问题是尝试使用之前评论中所述的 Google Docs 之类的工具,而不是真正专注于编辑 HTML 的工具。

      是的,这两种都是所见即所得的,但我不认为 GDocs 的目的是生成漂亮的 HTML,而是专注于提供 MS Word 的替代品,即使他们必须同时创建奇怪的 HTML路。

      我真不敢相信您已经研究了好几个星期,而且您还没有使用 CKEditor 或 TinyMCE。两种解决方案都包括使用属性、类或样式作为输出的选项,只需查看示例、阅读一些文档并根据需要进行调整。

      【讨论】:

      • 我不想将 Google Docs 用作 HTML 编辑工具。这只是 contenteditable 生成的输出示例。
      • 事实是 Google Docs 没有使用 contentEditable: googledocs.blogspot.com/2010/05/…
      • 即使是现在,一年多过去了,iPad Safari 甚至不支持 contentEditable,导致像 TinyMCE 这样的基于 contentEditable 的解决方案在它上面毫无用处。如前所述,Google Docs 使用完全基于 Java 脚本的编辑实现,并带有一个 2 像素宽的小 div 元素作为光标!
      • 很快,CKEditor 和 TinyMCE 的新版本将发布,包括对 iOS5 的支持,所以情况发生了一些变化。另一个问题是使用平板电脑编辑内容是否有用,或者最终还是使用物理键盘更好。
      【解决方案5】:

      我在 Content Editable Text Editors 中回答了非常相似的问题 - 为什么会出现这种情况以及我们作为所见即所得编辑器的作者可以做些什么。

      是的,我知道这个问题已有 2 年历史了,但它仍然是最新的。

      【讨论】:

        【解决方案6】:

        Medium.js!!

        Medium.js 将 HTML 代码保持在 contenteditable 语义、简单、 和清洁。 Medium.js 还支持占位符、自动 HR(或 BR、 或 P) 创建、事件、热键、简单和复杂元素 注射,还有更多!

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2018-06-01
          • 1970-01-01
          • 1970-01-01
          • 2023-03-22
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2015-01-17
          相关资源
          最近更新 更多