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

Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox ?Module

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 13 May 2010 21:45:48 -0700
Message-ID: <AANLkTimEFPOnItRZFcUIROmcTh-DUqiVSqdUxhf9CH9Z@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: "robert@ocallahan.org" <robert@ocallahan.org>, Adam Del Vecchio <adam.delvecchio@go-techo.com>, "www-style@w3.org" <www-style@w3.org>
On Thu, May 13, 2010 at 8:32 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> What is the purpose of (1a)? If author wanted "1fl" instead of "auto" they would have said so. Why make it a special case?

'auto' acts similarly to 1fl in most other flows.  By mapping auto
intelligently, you can reduce the amount of typing that authors have
to do in the common cases.

Specifically, this lets us continue to have the default of
"box-align:stretch" that the current draft has, without the author
doing anything special (since width defaults to 'auto', and padding
and margin default to 0).

> (3) is different from current spec in how it treats negative extra space. Is there evidence that current behavior is undesirable?

It's different because the model now uses absolute flex rather than
additive by default, so if you are completely ignoring the flexes
(that is, treating them as 0) and you still overflow, you can't get
any smaller.

> (4) should be unnecessary. If flex is allowed in padding (not that I agree it is a good idea), it should be clearly stated which set of flexes it belongs to. It should be either internal to Flexbox or external, not conditional.

I'm not sure I understand the objection.  It is clear which level it
belongs to.  If a flexbox is, itself, a child of another flexbox, then
any flexible padding on it is computed during the flex calculation of
its parent.  (And then flexible lengths in its children are computed
in its own, separate flex computation stage.)  Flexible padding on the
flexbox is useful enough, though, that we want to allow it even if the
flow of the flexbox's parent doesn't allow flexes.

> It is not quite clear from the algorithm if it is moving from "additive" flex to "absolute". It looks like it is absolute. Is it?

Yes.  You can get a nearly-the-same effect by using calc().

(The effect isn't *completely* identical because width:calc(20px+1fl)
won't ever flex smaller than 20px, while the current draft's
width:20px;box-flex:1; would, if necessary.  calc(20px+1fl) is instead
like width:0;min-width:20px;box-flex:1;.)

Received on Friday, 14 May 2010 04:46:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:46 UTC