不知道出于什么考虑,几乎所有的浏览器都默认设置了不打印背景色和背景图片。
而想打印出背景是无法通过页面代码来做到,必须设置浏览器的打印属性,这就大大降低了可靠性,因为有一定数量的用户根本就不知道还要设置一下才能打印出背景。
项目中一个页面必须满足打印的需求,由于所有小图片都整合到一起了,所以不是很想再拆出来。如果将大图position:absolute再套一个标签来显示某个区域来处理的话,就非常不合理,增加了额外的代码或脚本,而且没有加载样式时大图也破坏了整个页面结构,非常不好。
还是回归到了最原始的方法,拆成数个小图。
只是将必须打印的图片拆出来,可有可无的图片就不考虑了。
另外,禁止打印背景时,浏览器增加了一项不错的功能:将浅色文字加深,IE中如果文字颜色浅于#6E6863就会当成#6E6863来打印,如果深于#6E6863就不会变动,当用户选择了打印背景属性时,该功能就不再起作用;其他浏览器中也有类似的处理。
这个功能非常有用,不需要我们额外的去处理背景打印不了时“浅色文字深色背景”的情况了。
[不然的话,我们需要处理一下深色背景浅色文字的样式。因为深色背景色打印不出来的话,需要将浅色文字的颜色设置为深色,这样才不影响用户阅览。但这样的话,如果用户选择了“打印背景”属性怎么办呢?不就又看不到文字了?还要再把深色背景删掉,这样处理起来不是很好。]
先申明,并不是所有的IE都这样,跟版本有点关系。
刚开始我也很费解,为什么就变成空白了,其他浏览器都正常。诡异的是,右键查看源代码时能看到完整的代码,可就是显示空白,IE Developer也读不到内容。
网上查了一下,原来是IE在识别utf-8时出了点问题。
IE 解析网页编码时是 HTML 內的标识优先的,然后是 HTTP header ;而mozilla 系列的浏览器刚刚好相反。一般情况在,很多人是把
排在最前面,并且在title中就出现了UTF-8中文,这样, IE在解析时,就先遇到UTF-8,不往下解析了。
当出现这种情况时,把有中文的title放到<meta http-equiv=”Content-type” content=”text/html; charset=UTF-8″ />后面就可以了。
浏览器是怎么解析CSS的呢?
首先让我们来认识一下CSSStyleDeclaration,DOM CSS的一员,也是分量最重的一个。所有的CSS都会被解析到CSSStyleDeclaration中,你可以通过它去读取CSS属性更改CSS属性。
无论你在哪里写CSS,无论你写了什么CSS,浏览器最后都会解析成一个或数个styleSheet,每个styleSheet又包含一个或多个cssRule,每个cssRule又包含零个或一个或多个style(即CSSStyleDeclaration)。这些CSSStyleDeclaration会和其他styleSheet中CSSStyleDeclaration以及相应标签中的CSSStyleDeclaration进行比较,根据权重的不同,最后生成computedStyle即最终我们所看到的样式。
举个例子:
<style type=”text/css”>
@import url(print.css);
b{color:yellow;}
</style>
上面的代码就会生成一个styleSheet,这个styleSheet中有两个cssRule,分别是“@import url(print.css);”和“b{color:yellow;}”,第一个cssRule中没有style(会有一个子styleSheet),第二个cssRule中包含一个style是“color:yellow;”。
注意:每个style标签都会生成一个独立的styleSheet。
另外需要说明的一点,也是容易混淆的一点:
其他标签中的style属性中的CSS不能看作是真正的CSS本身,如:<b style=”color:red”></b>,它只是标签style属性的数值,浏览器会根据这个值去更改真正的CSSStyleDeclaration。
其实大家平时经常在和CSSStyleDeclaration打交道,比如:this.style.display=”none” ,这条JS通常我们会简单的理解成更改this对象的style属性中的值,即style=”display:none”,事实上没那么简单。
从底层来说,这条JS是用来更改CSSStyleDeclaration的,这条语句中的style实际就是CSSStyleDeclaration,浏览器首先通过这条JS更改CSSStyleDeclaration中display的值,然后CSSStyleDeclaration的cssText值会跟着被修改,最后才传达到this标签的style属性。
这也是为什么this.style.color=”red!important”无法更改color值的原因,!important只是在生成computedStyle时比较CSS权重用的,CSSStyleDeclaration中的color值不会有!important的,如果给它了,会被认为是非法值,因此this.style.color=”red!important”是无效的。
更改CSSStyleDeclaration可以有多种方式,上面的this.style.display=”none”就是一种,也是最常用的最简单的一种,在某些特殊情况下我们也可以这样来改变:this.style.cssText=”display:none” 或者 this.setAttribute(”style”,”display:none”)(不过IE不支持setAttribute(”style”,”"))。
这里this.setAttribute(”style”,”display:none”)又是另外一种情况了,它先去更改style属性的值,然后再更改CSSStyleDeclaration的值。
[说的有点混乱,有什么问题就一起探讨吧,希望都能有所收获]
在Firefox3中发现一个灵异的现象,如果给input设置了height和padding,在普通情况下不会有什么问题,但是如果input出现在iframe里的页面中有时候就会导致input的height不正常。
在项目中,我把程序生成的页面另外保存了一份,iframe设置同样的src,里面的input居然正常了。检查了文件编码和HTML代码,以及CSS,没有发现任何异常。
在官方的bugzilla中也找到了某人提的bug,但没有出来解决方法,你可以用Firefox3访问这个地址:
https://bugzilla.mozilla.org/show_bug.cgi?id=398959
https://bugzilla.mozilla.org/attachment.cgi?id=341749
https://bugzilla.mozilla.org/show_bug.cgi?id=403558
https://bugzilla.mozilla.org/attachment.cgi?id=288409
测试:
更灵异的事情发生了,以上测试,单独写一个页面是不会出现问题的,点击上面的“View”弹出的页面中,无论FF3还是FF2都会出现height不正常。
单独写一个页面是什么效果?可以看这个:
http://blog.xhlv.com/lab/ff_input_height_bug/index.html
http://lab.xhlv.com/ff_input_height_bug/index.html
两个一模一样的页面,在不同服务器上,有的会出现bug,有的不会出现,有时会出现,有时不会出现,郁闷。。。。
Why???
(暂时的处理方法是:去掉height,只用padding….)