On Friday, May 11, 2012, Daniel Holbert wrote: > On 04/30/2012 03:51 PM, Tab Atkins Jr. wrote: > >> # Computed Value: > >> # ‘auto’ computes to parent's ‘flex-align’; otherwise > >> # as specified > >> # [...] > >> # A value of ‘auto’ for ‘flex-item-align’ computes to > >> # the value of ‘flex-align’ on the flexbox item's flexbox. > >> > >> http://dev.w3.org/csswg/css3-flexbox/#flex-item-align > >> > >> I see two ways to handle this situation: > >> (a) if there's no parent, 'auto' computes to 'stretch' > >> (the default flex-align value) > [...] > > > > Whoops, silly mistake. It should definitely be (a). I'll make the > > change shortly - fantasai and I are hip-deep in the Pagination section > > right now. > > I just wanted to follow up on this -- I don't think this > change has made it into the spec yet. > I made the change earlier today, actually - I was waiting for a WG resolution on it, which I got yesterday. Now, ''auto'' computes to the computed value of the main size property. Ooh, I just remembered that it's in my stack of uncommited patches right now. I'll commit it tomorrow. > Also: The two chunks of spec that I quoted above are a bit > contradictory. The former "Computed Value" chunk just refers to the > "parent" & is non-flexbox-specific, whereas the prose below it refers to > the "flexbox item's flexbox" & leaves it undefined what "auto" would > compute to in non-flexbox contexts. > > I strongly prefer the more general language in the "Computed Value" > chunk, rather than the flexbox-specific prose. > Luckily, the issue here with not knowing whether a child is an item or not has been resolved - HTML's replaced elements are now *always* flexbox items regardless. This means that whether something is a flexbox item or not is based purely off of computed-time information, so I can go back to having these properties refer to flexbox items. ~TJReceived on Saturday, 12 May 2012 09:50:11 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC