Re: [css-align][css-flexbox] What does "justify-content: stretch end" compute to on a flex container?

On Fri, Nov 13, 2015 at 9:28 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Nov 11, 2015 at 2:13 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
>> The css-align spec says, for flex containers, justify-content: stretch
>> computes to flex-start:
>>   # Flex Containers:
>>   # [...]
>>   # The justify-content property [...]
>>   # since flexing in the main axis is controlled
>>   # by flex, 'stretch' computes to 'flex-start'.
>>
>> https://drafts.csswg.org/css-align-3/#propdef-justify-content
>>
>> This is per a thread & CSSWG resolution [1] earlier this year.
>>
>> This doesn't explain what happens if there's a fallback value, though.
>> For example: what should the computed value be for e.g.
>>   "justify-content: stretch flex-end"
>>
>> My first guess is that just the "stretch" part should be converted,
>> which means this would compute to...
>>   "justify-content: flex-start flex-end"
>> ...but that's not a valid value.  "justify-content" would accept
>> <content-distribution> followed <content-position>, but here we've now
>> got two adjacent <content-position> which it does not accept.
>>
>> My second guess is that this should just compute to "flex-start", and we
>> simply disregard the fallback value (and similarly ignore safe|true if
>> they're specified). This seems simplest, which is good. But if this is
>> what we want, we need to expand the spec-text about "stretch" computing
>> to "flex-start" in flex containers to more clearly call for this
>> handling of complex values.
>
> Yeah, I think your second solution is what we want.  The fallback
> alignment can just be ignored in that context.

Rather, now that we've adopted the change that "stretch" merely
*behaves as* "flex-start" in that situation, the problem is gone.  For
maximum clarity, tho, I have added a clarification stating that the
specified fallback alignment, if any, is ignored in this case.

~TJ

Received on Thursday, 3 December 2015 23:23:31 UTC