在pre标签中只使用CR作为linebreak是行不通的 [英] Using only CR as linebreak inside pre tag doesn't work

查看:148
本文介绍了在pre标签中只使用CR作为linebreak是行不通的的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在工作中,我们偶然发现了Bugzilla创建的HTML输出,导致线条太长,因为浏览器没有打破线条。
这发生在Chrome上,但不是Firefox 3.5上,所以我们并不在乎。但是Firefox 4的行为与Chrome一样,所以我们必须找到另一种解决方法。



一个例子是:

 < HTML> 
< body>
< pre>
Lorem ipsum dolor sit amet,consetetur sadipscing elitr,&#013; sed diam nonumy eirmod tempor invidunt ut labore et&#013; dolore magna aliquyam erat,sed diam voluptua。在vero eos&#013; et accamam et justo duo dolores et ea rebum。 Stella clita kasd&#013; gubergren,no sea takimata sanctus est Lorem ipsum dolor sit&#013; amet。&#013;
< / pre>
< / body>
< / html>

服务器仅使用CR作为非常罕见的换行符,而通常的替代方法(CR + LF ,只有LF)工作正常,所以解决这个问题的正确方法是告诉Bugzilla服务器使用这些换行方法之一。无论如何,我很好奇为什么这个
不起作用,而忽略换行似乎是浏览器的正确方式。



另外,我发现Chrome和FF 4使用Greasemonkey脚本的奇怪本地解决方法( this one ):

  var els = document.getElementsByTagName(*); 
for(var i = 0,l = els.length; i <1; i ++){
var el = els [i];
el.innerHTML = el.innerHTML;
}

看起来这对页面没有任何影响,但是通过这个脚本,突破线突然显示正确。



所以我的问题是:
$ b $ ol

  • Chrome / FF 4方式是处理< pre> 中的这类换行符的正确方式?

  • 为什么会这样Greasemonkey脚本工作吗?


  • 解决方案


    ),以动态地写入到DOM($ c> \ r )到LF( \\\
    )。

    请参阅 jsFiddle上的此测试。请注意第二行末尾的CR(十进制13)如何转换为LF(十进制10)。


    At work, we stumbled upon Bugzilla creating HTML output that led to lines much too long because the browser didn't break the lines. This was happening on Chrome, but not on Firefox 3.5, so we didn't really care. But Firefox 4 behaves just like Chrome, so we had to find another workaround.

    An example is:

    <html>
      <body>
        <pre>
          Lorem ipsum dolor sit amet, consetetur sadipscing elitr,&#013;sed diam nonumy eirmod tempor invidunt ut labore et&#013;dolore magna aliquyam erat, sed diam voluptua. At vero eos&#013;et accusam et justo duo dolores et ea rebum. Stet clita kasd&#013;gubergren, no sea takimata sanctus est Lorem ipsum dolor sit&#013;amet.&#013;
        </pre>
      </body>
    </html>
    

    The server is using only CR as a linebreak which is very uncommon and the usual alternatives (CR+LF, only LF) work correctly, so the right way to fix this is to tell the Bugzilla server to use one of these linebreak methods. Anyway, I'm curious why this doesn't work and ignoring the linebreaks seems to be the "correct" way for browsers.

    Also, I found a strange local workaround for Chrome and FF 4 using a Greasemonkey script (modified version of this one):

    var els = document.getElementsByTagName("*");
    for(var i = 0, l = els.length; i < l; i++) {
      var el = els[i];
      el.innerHTML = el.innerHTML;
    }
    

    It seems this would've no effect on the page, but with this script, linebreaks suddenly are showing correctly.

    So my questions are:

    1. Is the Chrome/FF 4 way the "correct" way to handle these kinds of linebreaks inside <pre>?
    2. Why is this Greasemonkey script working?

    解决方案

    The GM script works because apparently JS converts CR's (\r) to LF (\n), dynamically on writes to the DOM.

    See this test at jsFiddle. Notice how the CR (decimal 13), at the end of the 2nd line, gets converted to LF (decimal 10).

    这篇关于在pre标签中只使用CR作为linebreak是行不通的的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

    查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆