在工作中，我们偶然发现 Bugzilla 创建了 HTML 输出，由于浏览器没有中断行，导致行太长。这发生在Chrome上，但不发生在Firefox 3.5上，所以我们并不关心。但是Firefox 4的行为就像Chrome一样，因此我们必须找到另一种解决方法。
一个例子是：
<html>
<body>
<pre>
Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et
dolore magna aliquyam erat, sed diam voluptua. At vero eos
et accusam et justo duo dolores et ea rebum. Stet clita kasd
gubergren, no sea takimata sanctus est Lorem ipsum dolor sit
amet.
</pre>
</body>
</html>
服务器仅使用 CR 作为换行符，这非常罕见，通常的替代方案（CR+LF，仅 LF）工作正常，因此解决此问题的正确方法是告诉 Bugzilla 服务器使用这些换行方法之一。无论如何，我很好奇为什么会这样不起作用，忽略换行符似乎是浏览器的"正确"方式。
另外，我发现了一个奇怪的本地解决方法，使用Greasemonkey脚本（这个脚本的修改版本）：
var els = document.getElementsByTagName("*");
for(var i = 0, l = els.length; i < l; i++) {
var el = els[i];
el.innerHTML = el.innerHTML;
}
这似乎对页面没有影响，但是使用此脚本，换行符突然正确显示。
所以我的问题是：
- Chrome/FF 4 方式是处理
<pre>内部此类换行符的"正确"方法吗？ - 为什么这个 Greasemonkey 脚本可以工作？
GM 脚本之所以有效，是因为显然 JS 在写入 DOM 时动态地将 CR 的 （r） 转换为 LF （n）。
在jsFiddle上看到这个测试。 请注意第二行末尾的 CR（十进制 13）如何转换为 LF（十进制 10）。
是的，HTML RFC 将换行符定义为：http://www.w3.org/TR/html401/struct/text.html#line-breaks
换行符定义为回车符 （
）、换行符 （
） 或回车符/换行符对。所有换行符构成空格。
但是，光秃秃的回车极为罕见。 我并不惊讶它不起作用。 但从技术上讲，我会说FF4和Chrome是错误的。
不知道为什么你的油脂猴子脚本在工作。 我的猜测是，获得el.innerHTML是将CR转换为CR-LF或LF。