我应该编写 Polyglot HTML5 文档吗?

Should I write Polyglot HTML5 documents?

提问人:Tim 提问时间:6/24/2010 最后编辑:unorTim 更新时间:3/10/2016 访问量:1968

问:

我一直在考虑将我当前的 HTML5 文档转换为多语言 HTML5 文档。我认为,即使它们只是作为 ,编写 XML 的额外检查也有助于保持我的编码习惯整洁和有效。text/html

在纯HTML5领域,有什么特别激动人心的事情会让这个选择变得不明智吗?

其次,关于如何验证多语言文档的规范有点模糊。我假设基础知识是:

  1. 以 HTML5 形式通过 W3C 验证器运行时没有错误
  2. 通过 XML 解析器运行时没有错误

但是我是否遗漏了其他规则?

第三,鉴于它是一个多语言,有没有人知道为支持浏览器和不支持浏览器提供它的任何警告?application/xhtml+xmltext/html

编辑:经过一些实验,我发现像 XHTML5 这样的实体(没有 DTD)会中断。XML解析器有点像一把双刃剑,我想我已经回答了第三个问题。 

HTML xhtml 多语言标记

评论

0赞 Peter Krauss 2/12/2015
这个问题需要更新(现在HTML5是一个推荐!...另请参阅 stackoverflow.com/q/28419046/287948

答:

0赞 Ned Batchelder 6/24/2010 #1

这听起来像是一件非常困难的事情。XHTML的缺点之一是它不可能成功地在XML和老式HTML的竞争需求之间游刃有余。

我认为,如果你编写HTML5并成功验证它,你将拥有一份任何人都需要的整洁有效的文档。

评论

0赞 cboettig 10/29/2012
不确定是否像任何人需要的那样整洁有效。 考虑 xmlplease.com/xhtml/xhtml5polyglot/#s1
1赞 Warren Rumak 6/24/2010 #2

鉴于 W3C 关于 HTML 和 XHTML 之间差异的文档甚至还没有完成,可能不值得你花时间尝试多语言。反正还没有......再给它几年时间。

无论如何,只有在极其狭隘的情况下,您才应该出于某种特定目的积极计划将 HTML 解析为 XML,您才应该在 XML 合规性上投入额外的时间。纯粹为了 Web 浏览器的使用而这样做没有任何好处——只有缺点。

6赞 Alohci 6/24/2010 #3

定义如何创建 HTML5 多语言文档的工作目前正在进行中,但请参阅 http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html 的早期草案。这当然是可能的,但它确实需要大量的编码纪律,你需要决定它是否值得付出努力。虽然我创建了HTML4.01/XHTML1.0多语言文档,但我使用XML工具链创建它们,该工具链保证了XML的格式,并具有专门的代码来确保与HTML非void元素和有效XML字符的兼容性。直接手动编码将非常困难。

HTML5 中当前一个已知的问题是 iframe 元素的 srcdoc 属性。由于属性的值包含标记,因此需要对某些字符进行转义。HTML5 规范草案描述了如何为 HTML 序列化执行此操作,但没有(我上次查看)如何在 XHTML 序列化中执行此操作。

评论

4赞 Tim 6/25/2010
感谢您的指导!我从来不喜欢 iframe。他们似乎总是像“哟哟,我听说你喜欢网页,所以我在你的网页中放了一个网页,这样你就可以在冲浪时冲浪”。
0赞 Brett Zamir 6/22/2011 #4

此 wiki 包含一些 W3C 文档中没有的信息:http://wiki.whatwg.org/wiki/HTML_vs._XHTML

4赞 Beni Cherniavsky-Paskin 11/25/2015 #5

我来晚了,但 5 年后这个问题仍然很重要。 一方面,关闭我所有的标签强烈吸引我。对于阅读它的人来说,为了更容易编辑,为了伟大的正义。OTOH,看看多语言规范的血腥细节——http://www.sitepoint.com/have-you-considered-polyglot-markup/ 最后有一个方便的总结——我很清楚我无法用手把它好。

https://developer.mozilla.org/en/docs/Writing_JavaScript_for_XHTML 还对XHTML失败的原因进行了有趣的解释:选择使用XML MIME类型在运行时会产生各种副作用。到现在为止,好的 JS 代码处理这些应该是例行公事(例如,在比较之前总是小写的标签名称),但我不想要所有这些。有足够多的跨浏览器问题可以按原样进行测试,谢谢。

所以我认为有一个有用的中间道路:

  1. 目前仅作为 .不用担心它实际上会在 HTML 和 XML 模式下解析为具有相同运行时行为的完全相同的 DOM。text/html

  2. 只有努力让它解析为一些格式良好的 XML。它帮助读者,帮助编辑,它让我在自己的文档上使用XML解析器。

    不幸的是,多语言工具很少甚至不存在——甚至很难以一种同时满足 HTML 要求的方式序列化 XML......

    • 不用费吹灰之力:始终自行关闭 void 标签 () 并单独关闭非 void 标签 ()。<hr/><script ...></script>

    • 不费吹灰之力:使用小写标签和 attr(除了一些 SVG,但外来内容无论如何都使用 XML 规则),始终引用属性值,始终提供属性值(比 stanalone 更冗长,但我可以忍受)。selected="selected"selected

    • 内联,最烦人。我不能在不破坏XML解析的情况下使用或内部。我需要:<script><style>&<

      <script>/*<![CDATA[*/
         foo < bar && bar < baz;
      /*]]>*/</script>
      

    ...仅此而已!不关心XML命名空间或匹配HTML的表隐含DOM会降低大约一半的规则:-)

  3. 等待将来我可以直接去创作 XHTML,跳过多语言。这样做的好处是,我将能够忘记标签关闭的限制,能够直接使用XML工具使用和生成它。当然,现在忽略 xml 命名空间和其他东西会使切换更加困难,但我认为我将来会创建比转换现有文档更多的新文档

    事实上,我不完全确定是什么阻止了我现在生活在那个未来。只有IE 8吗?我也有点担心全有或全无的错误处理。我非常希望未来的 HTML 规范能够找到一种方法来缩小 HTML 与 XML 的差距,例如让浏览器接受 HTML 和 HTML,同时仍然保留 HTML 错误处理。<hr></hr><script .../>

    还有,工具。拥有可以序列化为多语言标记的多种语言的库将使程序生成它成为可能。拥有验证和转换 HTML5 <>多语言<> XHTML5 的工具会有所帮助。否则,它几乎注定要失败。

1赞 Chinoto Vokro 3/10/2016 #6

你应该吗?是的。但首先要澄清几点。

发送标头仅意味着它应该通过XML解析器,据我所知,它仍然具有HTML5的所有优点。
关于,这未在 XML 中定义,XML 定义的唯一字符实体引用是 lt、gt、apos、quot 和 amp,您需要对其他任何内容使用数字字符引用。nbsp 的代码是 or ,我个人更喜欢十六进制,因为 unicode 码位是这样表示的 (U+00A0)。
Content-Type: application/xhtml+xml&nbsp;&#xa0;&#160;

发送标题对于测试很有用,因为您可以快速发现标记的问题,例如未关闭的标签、杂散的结束标签、可以解释为标签的文本等,基本上可能会破坏网站的外观甚至功能。
在我看来,最重要的是,如果您允许用户输入并且无法解析,这通常意味着您没有逃避他们的数据,并且使自己容易受到漏洞的影响。解析为 HTML,在有人开始注入脚本来骚扰您的用户或窃取数据之前,您可能永远不会注意到问题。

这个页面很好地解释了什么是多语言标记:https://blog.whatwg.org/xhtml5-in-a-nutshell

评论

0赞 Tim 3/10/2016
实际上,今天我会用“不”来回答我自己的问题。维护有效文档的唯一万无一失的方法是生成 (X)HTML5,并且永远不要发送任何原始的人工生成数据。因此,如果您已经打算使用生成器,您不妨生成 HTML5,并让您的生成器在文档到达浏览器之前将您的输入或原始数据验证为可预测的输出。通过模板引擎(如 haml 或 slim-lang)(带有解析器的东西)生成,或者通过视图渲染引擎(如 React)生成。
1赞 Chinoto Vokro 3/15/2016
我已经写了几年的多语言标记,我从来不需要任何东西(为了方便起见,我把它包装在一个函数中)来处理 PHP 中的用户生成的内容,或者我把它作为 JSON 和设置提供给 javascript(适用于重复标记)。我很好奇你觉得它这么困难。htmlentities($dirty,ENT_QUOTES|ENT_XML1|ENT_SUBSTITUTE,"UTF-8",true)textContent