Re: [css3-sizing] intrinsic widths of replaced elements inside flexboxes

On Wed, Feb 13, 2013 at 10:18 AM, Ojan Vafai <ojan@chromium.org> wrote:

> On Tue, Feb 12, 2013 at 6:02 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 2/12/13 8:56 PM, Boris Zbarsky wrote:
>>
>>> Most of the tests in here have no constraint that would cause them to go
>>> below their max-intrinsic width, so it doesn't matter what the
>>> min-intrinsic width is.
>>>
>>
>> Oh, and the point is that the table cell test _does_ have such a thing in
>> it: that other table cell that takes up all the available space.
>
>
> Ugh. Yup. I realized this as I was going to bed last night. :) OK, so this
> has nothing to do with table cells.
>
>  On Tue, Feb 12, 2013 at 4:25 PM, L. David Baron <dbaron@dbaron.org>
>  wrote:
>
>> On Tuesday 2013-02-12 16:13 -0800, Ojan Vafai wrote:
>> > TL;DR: I think we need to add something like the following to the
>> > css3-sizing spec: The min-measure *contribution* of a replaced element
>> with
>> > a percentage width to the min-content measure of a table cell is 0.
>>
>> I think the "contribution" idea here is correct; the 'width',
>> 'min-width', and 'max-width' properties on an element do not affect
>> its own min-content width, but they do affect the min-content width
>> of its parent.  When I wrote http://dbaron.org/css/intrinsic/ I used
>> the term "outer minimum intrinsic width" for what you call
>> "contribution" (though it also involved adjusting from content-box
>> to margin-box widths).
>>
>
> I was just using the terminology of http://dev.w3.org/csswg/css3-sizing.
>
> Now that we have a better test case that makes the available width 0, I
> have more clarity on what questions need to be resolved.
>
> 1. The spec needs to say something to the effect of "The min-measure
> contribution of a replaced element with a percentage width is the border
> and padding measure of that element." Or should it be 0? WebKit does 0. IE,
> Gecko, Opera seem to use the border and padding width.
>
> Action needed: The spec clearly needs to change. IMO, using the
> border/padding width makes the most sense, but I'd be OK with just using 0
> as well.
>

WebKit's behavior at tip of tree is now to do this if either the width or
the max-width is a percentage value. Talking to Gecko engineers, it sounds
like they are considering changing to match (i.e. applying this behavior
for percentage max-width in addition to width).


> 2. If there is border and/or padding, IE still resolved the 100% width on
> the image against the 0 available width, so the image sizes to 0.
> Opera/Gecko size the image height to the border and padding height, and
> then increase the width to maintain the aspect ratio and the image
> overflows it's container here.
>
> Action needed: We need to decide something here and put it in the
> appropriate spec. The IE behavior seems the most sensible to me, but this
> is all a weird edge case and I'm open to any behavior as long as we can all
> agree on it.
>
> 3. Except for the flexbox case, WebKit doesn't actually shrink the image
> itself.
>
> Action needed: WebKit's the only one that does this. We should just change
> to match other browsers here.
>
> 4. In the flexbox case, Gecko/WebKit don't apply the min-width: auto ==
> min-width: min-content to the image. The min-content measure of the image
> is not 0 even though it's min-measure contribution is, so min-width:
> min-content should cause the image to be it's intrinsic size.
>
> Action needed: This looks like a bug to me. Gecko/WebKit just need to fix
> this.
>

Now that we're reverting the min-width:auto change for flexboxes, this is
obviously resolved.