W3C home > Mailing lists > Public > www-style@w3.org > May 2014

Re: [css-flexbox] Better define the computed value of 'flex-basis'

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 07 May 2014 11:57:39 -0700
Message-ID: <536A8223.3080005@inkedblade.net>
To: www-style@w3.org
On 05/07/2014 11:16 AM, Tab Atkins Jr. wrote:
> Right now 'flex-basis' has its computed value defined as "as
> specified, with lengths made absolute".  This implies that
> "flex-basis: auto" (which means "use the value of width/height") stays
> as "auto" in the computed value, and it's not well-defined when this
> changes into the width/height value.
> fantasai and I propose that we define that "flex-basis: auto" computes
> to the width/height value.  Rossen concurred in a private discussion.
> This has some implications, which we think are acceptable.  In
> particular, it means that if a flex item has "flex-basis: auto", and
> it's also a flexbox and has a child with "flex-basis: inherit;", the
> child won't inherit the "auto" value - it will instead inherit the
> width/height value that "auto" computes to.  (Which might be "auto"!
> ^_^)  Use of "flex-basis: inherit;" is likely to be so rare that the
> confusion this might cause is irrelevant, however.

Some more info:
   This gives more useful information via getComputedStyle(), which
   is probably a better use case than inheriting 'flex-basis'.

   Also it allows animating from pass-through 'width' value to an
   explicit 'flex-basis'. Not a great use case, either, but probably
   more useful than inheriting 'flex-basis'.

   It does require looking at the 'flex-direction' value on the parent
   of the element to figure out which of 'width' or 'height' to use.
   Technically, there might be some intermediary box-fixup stuff, which
   may result in 'auto' computing to a 'width' or 'height' value on a
   non-flex-item box, but for flex items it should always give the
   right answer.

We're particularly interested in hearing from dbaron and dholbert.

Received on Wednesday, 7 May 2014 18:58:06 UTC

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