W3C home > Mailing lists > Public > www-style@w3.org > July 2013

Re: [css-flexbox] min-width/height: min-content defaults for replaced items and overflow containers

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 22 Jul 2013 10:54:15 -0700
Message-ID: <51ED71C7.4010009@inkedblade.net>
To: www-style@w3.org
On 07/19/2013 12:14 PM, Tab Atkins Jr. wrote:
>
> This level of additional complication, where the meaning of a
> 'min-width' keyword depends on 'overflow', was something we were
> uncomfortable with.  I prefer something that imposes slightly more
> work on authors in some cases in return for simpler-to-understand
> behavior overall, so that when the defaults fail, it's easier to
> figure out how to fix it through simple fiddling.  Changing
> 'visibility' is *not* something that someone will think of unless
> they are actively reading the spec.

Nobody is proposing to change 'visibility'. And the fix for cases
that need to be tweaked will be to adjust the min-size, which is
fairly well related to the behavior that needs adjusting (not
shrinking enough).

> Given that the fix for this case in current WK/B/FF code is to
> manually set flex-shrink to 0, that shouldn't break existing pages
> much at all.
>
> This would give us all the benefits of the ED behavior, while fixing
> its biggest failure mode, and without screwing with any other cases.

You mean, setting flex-shrink to 0 on <img>, <object>, etc. in the
UA style sheet?

>>    Case #3:
>>
>>      Hidden in Elliott's case is the distinction between intrinsic size
>>      and declared size. Suppose the image's intrinsic width is not 200px,
>>      but 400px, but the author declared its 'width' property as '200px'.
>>
>>      If we use its min-content size as a minimum, its size floors at
>>      400px, not 200px, which is probably quite surprising to the author.
>>      Which is why the automatic minimum, if any, should not be greater
>>      than the specified size. This is a problem with the current CR.
>
> This might be an issue with the definition of min-content itself, to
> be honest.  For "scalable" elements, the min-content width/height
> shouldn't be larger than the specified size (perhaps only if the
> specified size is a definite length).

I think you're way mixed up here... min-content's definition is correct.
We're just not being careful about how we're using it in Flexbox. Think
about it a bit more. :)

>> I tried to extract cases from the original thread on this topic, but
>> there were no specific examples, just generalized complaints. :(
>>    http://lists.w3.org/Archives/Public/www-style/2013Feb/0364.html
>
> This is just case #4, except that some of the complaints were even
> stronger, about nested flexboxes (particularly when they have
> different flex-direction values). Making the entire flexbox huge is
> confusing and frightening, and hard to debug.  Having the items
> overflow the flexbox looks similar if you just stare at the results,
> but is *much* easier to debug, because dev tools correctly show the
> sizes/bounds of items so you can tell that it's an overflow problem.
> You then smack your forehead and curse that "overflow:visible" is the
> default, as usual.

Can you give specific examples? Because last time we discussed this,
you gave exactly such a handwavy explanation, saying there were problems
in the CR (but not giving any specific examples), and asserted that your
proposed fix would have no problematic implications. And then Elliott
posted some. So, I don't feel inclined to trust your handwavy explanations.
Show me the code.

~fantasai
Received on Monday, 22 July 2013 17:54:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC