W3C home > Mailing lists > Public > www-style@w3.org > November 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 13 Nov 2015 11:28:43 -0600
Message-ID: <CAAWBYDA98txegBSxisdME-MpAPFrREH4t+YFPJhgx15GhxA0qQ@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: www-style list <www-style@w3.org>
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.

Received on Friday, 13 November 2015 17:29:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC