W3C home > Mailing lists > Public > www-style@w3.org > February 2012

[css3-flexbox] main-axis margin:auto (RE: [css3-grid] [css3-flexbox] Stretch alignment in flexbox and grid)

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Sat, 18 Feb 2012 03:09:56 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: "www-style@w3.org list" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928412E60F9B@TK5EX14MBXC214.redmond.corp.microsoft.com>
So what do you think about margin:auto alignment after flex and before pack? 

You wanted that and now even I like this version of it (because the margin step is trivial, it doesn't complicate flex algorithms and it doesn't need new syntax of values...)

I particularly like that a single inflexible child with "margin:auto" and all defaults will get centered on box axes. That's kinda cool. And the same single child in a single cell grid does exactly same, which is not bad too...

-----Original Message-----
From: Alex Mogilevsky [mailto:alexmog@microsoft.com] 
Sent: Tuesday, February 14, 2012 2:31 PM
To: Tab Atkins Jr.; Phil Cupp
Cc: www-style@w3.org; fantasai (fantasai.lists@inkedblade.net)
Subject: RE: [css3-grid] [css3-flexbox] Stretch alignment in flexbox and grid

± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
± Sent: Tuesday, February 14, 2012 2:05 PM 
± > Note I think the same rules should probably apply to flex-pack: 
± > justify as well, since it seems like another form of stretching.
± I don't understand.  flex-pack:justify doesn't stretch anything - it 
± distributes the free space around the items.  The analogue of "stretch" in 
± the main axis is making the item flexible.
± (flex-align:stretch is just the keyword version of making the cross-size 
± flexible.)

Actually I was thinking that if margins work on main axis it should be just like in alignment: *after* item sizing and *before* pack.

Then (again just like in alignment), if there are any auto margins on main axis, pack mode doesn't matter, margins will do the job, with some manual control available.

Note that this would be different from treating auto margins as "flex:1" that I was opposed to (still am). Wiring margins into flex calculations with only partial set of input screams incomplete and is asking for adding more controls. But letting auto margins do what they do elsewhere seems useful.

So, if the rules were:
    1) do flex
    2) if there is any space left, 
        a) if there are auto margins on main axis, 
           each gets equal share of free space. Pack is not necessary.
        b) otherwise apply pack

Then spacing non-flexible autosize items becomes piece of cake - and pretty much no learning required other than realizing that it finally works:

    <div style="display:flexbox; width:100%; height:100%;">
         <div style="margin:auto">
             Woohoo! I am centered!

Sure, it can be done without margins:

    <div style="display:flexbox; width:100%; height:100%; flex-pack:center;">
         <div style="flex-item-align:center;">
             Woohoo! I am centered!

But if you could do either, which would you remember first?

± I think auto margins should continue to resolve to 0 in the main axis.
± Flexible margins are incompatible with multi-line flexboxes - *none* of the 
± flex-pack values can be simulated with margins in a multi-line flexbox 
± unless you know precisely where breaks will occur ahead of time. 

Actually 'distribute' can be done with margins.

± Flexible margins *can* do somewhat useful things in a single-line flexbox (they can 
± be used to simulate XUL springs), but I don't think it's worth it to include 
± them.
± (I don't really think that flexible auto margins in the cross axis are worth 
± it, either, but Alex seems to feel strongly, and I don't have a technical 
± argument against them, just an aesthetic one.)

BTW I don't feel strongly either way. Only moderately strong.

I think letting margins work keeps it more consistent with the rest of CSS, it is easy to implement (no margin collapsing, don't even think about it). Oh, and if we choose to set auto margins to zero we can't change it later without a new keyword for margin, which will not be particularly elegant.

Received on Saturday, 18 February 2012 03:10:32 UTC

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