Re: [css-align] Should 'justify-content:stretch' *compute to* or *behave like* flex-start, in a flex item?

On Tue, Nov 24, 2015 at 2:30 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
> In light of the recent thread[1] about css-align & 'left'/'right' being
> converted to sensible values *at used-value time* instead of at
> computed-value time: I have a similar question about
> "justify-content:stretch" & flex containers.
>
> The css-align spec says[2] that "justify-content:stretch" *computes* to
> flex-start, on flex containers:
>   #  since flexing in the main axis is controlled
>   #  by 'flex', 'stretch' computes to 'flex-start'.
> Is there a reason it chooses to do this, as opposed to just having
> "stretch" *behave* like "flex-start" as a used value in a flex container?
>
> (Moreover: this special computation behavior contradicts the "Computed
> value: specified value" line in the justify-content/align-content
> property definition.  If we really want this special computed-style
> behavior, then that line needs an exception added.  But I'd really like
> for us to just do away with this special computed-style.)
>
> Thanks,
> ~Daniel
>
> P.S. This special "stretch" computed-value behavior made more sense back
> when "auto" computed to "stretch", in an older version of the css-align
> spec -- then, the new initial value "justify-content:auto" would compute
> all the way to its old value, "flex-start", on a flex container. But
> given that "auto" computes to itself now[3], that won't happen anymore.
>  So it seems like we should just have "stretch" compute to itself too.
>
> [1] https://lists.w3.org/Archives/Public/www-style/2015Nov/0284.html
> [2] https://drafts.csswg.org/css-align-3/#content-distribution
> [3] https://lists.w3.org/Archives/Public/www-style/2015Oct/0023.html

fantasai and I reviewed this, and agree that it no longer makes sense
to have "stretch" compute to "flex-start", for the reasons you gave.
We've fixed it to say "behaves as".  This removes the last "computes
to" behavior in justify-content, so there's no longer any
computed-value dependency there.

~TJ

Received on Thursday, 3 December 2015 22:27:11 UTC