そのタイトルは一口です ！したがって、100% の高さを持つ絶対配置の親要素があり、その子imgには 100% がありmax-heightます。現在、WebKit (Chromium25) と Opera (12) は親の計算/レンダリングされた幅をimg新しい (より小さい) 幅に合わせて縮小しますが、Gecko (FF21) はそれをimg(集合的な) 元の幅のままにし、親は大きな右パディング。
ここを参照してください: 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:
- 残念ながら、元の問題の解決策は次のとおりかもしれません。それは奇妙です。@Diodeus が指摘しているように、
position: absolutevs.には問題がありheight: 100%ます。私には、これが問題になることはありませんでした。両方のブラウザは、ビューポートの（最大）高さまで画像を縮小します（これが指定されていなくても）が、プレースホルダーは、少なくとも水平方向に正しくスケーリングされていません。私が知る限り。この許容誤差は、親コンテナーが小さくなるにつれて大きくなります。また、WebKit は親を縮小して子をきちんとラップしますが、サイズ変更後ではなく、ページの読み込み時にのみ実行します... - /がない私の回避策では、Gecko
position: absolute/height: 100%WebKit の不一致を発見しました: http://jsfiddle.net/b3TY5/3/ ; withbox-sizing: border-box(resp.-moz-box-sizing) WebKit は親を縮小して子の幅に合わせます (青の div は黄色の div よりも小さい) が、Gecko はそうしません (青と黄色の div の幅は同じです)。