- From: Greg Whitworth <gwhit@microsoft.com>
- Date: Mon, 12 Jan 2015 00:02:42 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>
- CC: www-style list <www-style@w3.org>
> I think the Chrome behavior is *better*, in that it seems to match intent well. > But I don't think it follows from the current definitions in Sizing, which is > almost certainly a Sizing bug; we've been pretty sure for a while that our > handling of intrinsic sizes of replaced elements is wrong. We also simply > dont' define what the min-content size contribution is of a replaced element, > so the current spec's answer to the question is mu. > 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). With that said, I'm not entirely sure this is the "best" end result. For example, if you remove the text completely Chrome doesn't show the image at all (http://jsfiddle.net/2hrLf81m/) which is not what you would want. I prefer what Gecko is doing in the example provided. Although, I'm not too passionate one way or the other. I guess the big question is, what should "content" represent and what is it's min? We seem to have interop on the longest word determining the max (http://jsfiddle.net/2hrLf81m/1/) when nothing else is included so does anyone have issues with adding: "If there is content that has an intrinsic size that has a larger max width than the current max of the longest word, make this the max." Greg
Received on Monday, 12 January 2015 00:03:11 UTC