Re: [css-flexbox] Should "max-width" influence the resolved flex base size? (from default "flex-basis:auto;width:auto")

On 02/20/2015 12:30 PM, Greg Whitworth wrote:
> I think there was a slight mis-communication because the fiddle you
> shared [1] did not have the flex-basis set to content, but to auto
> (which is the default value for flex-basis).

Yup -- though note that "flex-basis:auto; width:auto" is exactly equivalent to "flex-basis:content" (In other words, "content" is just the explicit flex-basis keyword, to describes the default behavior.)  Sorry for being a bit coy about using "content" -- I intentionally avoided focusing on that keyword because it's relatively new and not implemented in Firefox yet, so it's not usefully testable *via that keyword*. The behavior that "content" *describes* is testable everywhere, though, simply via "flex-basis:auto;width:auto".

> I created an update adding
> in flex-basis: content [2] along with a ref test. Firefox and IE are
> doing the same thing overall, but just for clarity here is how we
> implemented it.

(Firefox rejects "flex-basis:content" for now, as noted above, so I wouldn't suggest trusting our rendering too much when you're using that keyword.

I think that should only matter for .item2 in your fiddle, since that's the only place where you have a non-default "width" value which 'content' would be overriding.)

> We implemented it with max/min width being taken into account when
> flexing the items, but not when determining the flex base size; which in
> this case would be max content.

Cool -- that's my understanding of how things should work, too. (though I don't think the spec is clear about this right now)

> That said, we should clarify if min-width, max-width, min-height,
> max-height are to be considered a main size property[3] stated in 9.7.4D

I think (?) you're saying we should explicitly define what "min and max main size properties" means -- is that what you're getting at here? 

(Those terms are used in many places beyond 9.7.4D, but I don't think they're defined. It would probably be wise to define them.)

Or, if that's not what you're getting at here, could you reword/explain perhaps?

> and possibly an additional line that says not to take min & max
> width’s into account for 9.2.3D.

Yes, this is essentially the clarification that I'd like us to make here -- though it's needed more in 9.2.3E than in 9.2.3D.

9.2.3D says to produce the item's "max-content main size", and I think this is reasonably clear, because min/max-content sizes are already defined as being something intrinsic that's not influenced by the min/max properties on the element itself, IIUC. So I think this section is reasonably clear.

But 9.2.3E says to "lay out the item [...] using its used flex basis in place of its main size" and to get "the item’s resulting main size".  It's unclear whether this "lay out" step should include min/max clamping at some stage of the process, when producing a "resulting main size". I'd prefer we do *not* include a min/max clamp here, but Blink seems to have implemented the opposite interpretation of this section, and they can be easily forgiven for getting this interpretation from this chunk of spec-text.

Hence, clarification needed.

Thanks,
~Daniel

Received on Friday, 20 February 2015 21:28:39 UTC