- From: Greg Whitworth <gwhit@microsoft.com>
- Date: Mon, 12 Jan 2015 23:13:45 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
> I actually think that Chrome is more spec compliant here (unless I'm missing > something), as this is indeed the most narrow this content could be since the > word "programmer" is the longest word (which would cause the overflow). > > Can you point to what part of specs you think support that? As far as I can > tell, this situation is currently undefined in Sizing, since we don't define what > the min content contribution is for replaced elements. I am going off the definition of min-content inline-size since this was all text that made up the "content." It says: # The narrowest inline-size a box could take that doesn’t lead to inline-dimension overflow that # could be avoided by choosing a larger inline-size. Roughly, the inline-size that would fit around # its contents if all soft wrap opportunities within the box were taken. # (See Intrinsic Size Determination.) If this is being used by Chrome for determining the size of the <figure>, then "programmer" is the longest word and Chrome resizes the image to fit this width while Gecko uses the intrinsic size of the image (which seems to be the definition of min-content block-size). Greg
Received on Monday, 12 January 2015 23:14:13 UTC