http://jsfiddle.net/3BFGU/71/html元素的宽度小于个别子元素的宽度之和?
html父元素的宽度(使用1 $(el).width()1)计算的宽度小于子元素的合并宽度。
- 只发生在Firefox中。
任何想法为什么会发生这种情况?
http://jsfiddle.net/3BFGU/71/html元素的宽度小于个别子元素的宽度之和?
html父元素的宽度(使用1 $(el).width()1)计算的宽度小于子元素的合并宽度。
任何想法为什么会发生这种情况?
也许,总宽度是以前以某种方式四舍五入宽度和这些分数宽度的总和。该总和不等于容器的宽度。我发现更多元素会产生更多的不准确性,例如5个元素相差3个像素。
Actualy,嵌入式文本块可以具有分数宽度例如10.6px。因此,连续排列的三个块将占用31.8px≈32px。但是,当每个宽度四舍五入到总计≈11px * 3 = 33px。这是一个像素的偏差。 http://jsfiddle.net/3BFGU/86/
n.b. Firefox'字体渲染引擎开始使用亚像素字母放置只有当字体大小> 15px(至少对于Verdana,Arial和Segoe UI,这些应用都有极端暗示)。当每个字母的整数宽度值较小且字符串中的所有相同字母具有完全相同的栅格图像时。这behaivior清楚地看到与letter-spacing: .9px;
和font-size: 14.9px;
和font-size: 15.1px;
,一年前我做了间除此以外a little playground切换,以测试不同的浏览器的渲染引擎。
也发生了谢谢。如果您可以详细说明内联文本块可以具有小数宽度,那将很酷。 – sbr
看起来像Firefox中的错误....可能是一个舍入错误?
错误不一致。如果在第二个范围内添加一个空格,在'new'之后它会正确计算(我正在14.0.1上进行测试)。
http://jsfiddle.net/DigitalBiscuits/3BFGU/81/
此外,如果你再一次改变过去的“W”的资本,它正确地计算。 http://jsfiddle.net/DigitalBiscuits/3BFGU/83/
这将导致我相信这是Firefox的计算像素的大小的方式,并且必须有一些舍入,上或下,涉及这是造成这种差异。
我刚刚更新到15.0,并得到相同的结果。我会对所有版本进行测试,直到完全更新并让您知道结果。
同样再次15.0.1版,最新版本
确切的宽度正在计算时得到综合。这可能会导致ff显示这样的结果。
什么版本的Firefox?对我而言,15岁不会发生。 –
我正在使用15.0.1。夜间搭建的FF(版本17) – sbr