W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: [CSS3] Flexible Flow Module, proposal.

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 13 Apr 2009 10:46:58 +1200
Message-ID: <11e306600904121546u17041f14xbc64ce522aced416@mail.gmail.com>
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: David Hyatt <hyatt@apple.com>, www-style <www-style@w3.org>
On Mon, Apr 13, 2009 at 10:44 AM, Andrew Fedoniouk <
news@terrainformatica.com> wrote:

> David Hyatt wrote:
>> On Apr 12, 2009, at 5:19 PM, Robert O'Callahan wrote:
>>> That is not what I was asking for.
>>> Suppose I have elements A and B with intrinsic widths 100px and 200px
>>> respectively. Suppose the container has width 400px, and I want the extra
>>> space to be distributed equally to A and B, so they end up with widths 150px
>>> and 250px. Your proposal has no way to do this as far as I can tell, nor is
>>> it possible by setting min-widths or max-widths.
>>> This is actually the default behaviour for XUL boxes, so it seems
>>> important to me that any flex-box-like spec be able to do it.
>> Yeah, I just brought this up in my last message as well.  The only way I
>> can see to solve this for flex units is to actually specify both values,
>> e.g.,
>> width: (100px)1*
>> or something like that....
> I am not sure I understand the problem.
> If you will define:
> #A { width:max-intrinsic; padding-left:1*; padding-right:1* }
> #B { width:max-intrinsic; padding-left:1*; padding-right:1* }
> than widths of *border* boxes will be set in the way you want.
> Is this the answer or I've missed something?

That does not allow the children of A and B to occupy the extra width. The
extra width can only be white space.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
Received on Sunday, 12 April 2009 22:47:35 UTC

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