1

这标题真是一言难尽！所以我有一个绝对定位的父元素，高度为 100%，它的子元素有img100% max-height。现在，虽然 WebKit (Chromium25) 和 Opera (12) 缩小父级的计算/渲染宽度以匹配img新的（更小的）宽度，但 Gecko (FF21) 将其保留为imgs（集体）原始宽度，并且父级似乎有一个大右填充。

见这里： http: //jsfiddle.net/b3TY5/（大屏幕所有者：请调整浏览器窗口大小，以便灰色图像开始缩小）

现在我读到它position: absolute被过度使用（并且我找到了解决问题的方法），但我仍然会对

  • 使 Gecko 表现得像 WebKit 的解决方案（IMO WebKit 的方式更合乎逻辑。或者我错了吗？）
  • 对不同行为的解释，也许是关于未来遇到这种情况的最佳实践（但请比“不要使用绝对位置”更具建设性；）

谢谢！

编辑：我的解决方法并不完美，因为我最终得到了具有 100% 宽度的父元素，所以我不能有一个绝对定位的子元素right: 0。当我将父级设置为 时display: inline-block，WebKit 显示与 Gecko 相同的行为。参照。http://jsfiddle.net/b3TY5/1/并确保有一个非常小的结果窗口。注意第一个 div 的右填充。

编辑2：

  1. 恐怕原始问题的解决方案可能只是：这很奇怪。正如@Diodeus 指出的那样，position: absolutevs.存在问题height: 100%。对我来说，这从来都不是问题：两个浏览器都将图像缩小到视口的（最大）高度（即使没有指定）但它们的占位符至少在水平方向上没有正确缩放，因为据我所知。这个误差范围随着父容器变小而增加。虽然 WebKit 缩小父级以整齐地包裹其子级，但它仅在页面加载时这样做，而不是在调整大小之后......
  2. 在我的解决方法中 - 没有position: absolute/ height: 100%- 我发现 Gecko/WebKit 不一致：http: //jsfiddle.net/b3TY5/3/；with box-sizing: border-box(resp. -moz-box-sizing) WebKit 会缩小父级以匹配子级的宽度（蓝色 div 小于黄色），而 Gecko 不会（蓝色和黄色 div 宽度相等）。
4

0 回答 0