- From: Christian Biesinger <cbiesinger@google.com>
- Date: Tue, 1 Dec 2015 20:11:39 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
On Tue, Dec 1, 2015 at 8:09 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, Dec 1, 2015 at 5:01 PM, Christian Biesinger > <cbiesinger@google.com> wrote: >> On Tue, Dec 1, 2015 at 7:58 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>> On Tue, Dec 1, 2015 at 4:49 PM, Christian Biesinger >>> <cbiesinger@google.com> wrote: >>>> However that still leaves the preferred width computation which only >>>> says "Place all flex items into lines of infinite length.", which is >>>> quite the opposite of respecting any height or max-height properties. >>>> Shouldn't it be affected by that? >>> >>> No, "width: max-content;" never cares about the "max-width" property >>> on the element. (For the purpose of figuring out what "max-content" >>> resolves to - later, in actual layout, it of course matters.) >> >> No, that's not what I meant. This is still about how max-height should >> affect the max-content width. See the testcase I gave originally -- if >> a column flexbox has a max-height set, shouldn't the intrinsic width >> computation break the boxes into multiple lines and give a width that >> can fit the multiple flex rows (visually, the columns)? > > Your testcase doesn't invoke max-content at all. Your desired result > is what you get, yes, but from elsewhere in the algorithm, as fantasai > outlined. Huh? Why do you say that? It's an inline-flex, therefore shrink-wrapped, therefore should be sized at max-content. No? Yet the border/background-color is only around the first column in blink, right now. -Christian
Received on Wednesday, 2 December 2015 01:12:30 UTC