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

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.)


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

Received on Tuesday, 24 November 2015 22:31:28 UTC