RE: [css3-flexbox] alignment test

Can I break this question in two:

1) As far as what 2009 spec actually says, is my test and expected behavior correct? Such as do margin work the same way in horizontal and vertical box, is "center" a "true center" etc.? Regardless of what we want to do, I want to be sure I am reading that correctly

2) For potential changes to the new spec, I'll open an issue on wiki and send out a proposal. I can live with any of the options you've listed but I want to get a group resolution and specific text in the spec *soon* -- this is an important part of the spec and getting it solid would be really good for getting interoperable implementations.

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Saturday, December 10, 2011 12:15 PM
To: Alex Mogilevsky
Cc: Tony Chang; www-style@w3.org list; John Jansen; Arron Eicholz; Rossen Atanassov
Subject: Re: [css3-flexbox] alignment test

On Fri, Dec 9, 2011 at 7:35 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> ± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] ± Sent: 
> Wednesday, December 07, 2011 10:59 AM ± ± I was convinced against 
> main-axis auto margins being flexible, since they ± complicate the 
> layout model without really working well (since you can't ± control 
> the flexibility - I liked them a lot more when they accepted the 
> flex() ± function).  So, the spec currently resolves them to 0 instead 
> (or should, if I ± accidentally left out the detail).  This matches 
> both Firefox's and WebKit's ± behavior for -prefix-box.
> ±
> ± For consistency, cross-axis margins should do the same.  As far as I 
> can tell, ± this *also* matches Firefox's and WebKit's behavior.
>
> Consistency is a good thing, but it is just one of the reasons to consider. In normal flow, 'margin-left' and 'margin-right' work for alignment, but 'margin-top' and 'margin-bottom' don't (and those collapse too).

That inconsistency has plagued web developers since it was created.
;_;  I don't think we should propagate that badness to new layout modes if we can avoid it; it's not like we have collapsing margins to worry about dealing with.

> The margin alignment in 2009 spec is *consistent* with normal flow: if you change a container from "display:block" to "display:box;box-orient:vertical", children preserve their horizontal alignment.

Regardless of what the spec might be interpreted to say, auto margins in Flexbox do *not* work like auto margins in normal flow in the Moz or WebKit implementations.  As far as I can tell, auto margins always resolve to zero in Firefox, while horizontal margins do something broken in WebKit that *looks* correct in a vertical flexbox but is clearly, horribly, wrong in a horizontal flexbox, and vertical margins always resolve to zero.  The test I used was this:

<!DOCTYPE html>
<div class='flexbox v'>
  <div>foo</div>
  <div>foo</div>
</div>
<div class='flexbox h'>
  <div>foo</div>
  <div>foo</div>
</div>
<style>
.flexbox {
  display:-moz-box;
  display:-webkit-box;
  width:100px;
  height:100px;
}
.flexbox.v {
  -moz-box-orient: vertical;
  -webkit-box-orient: vertical;
}
.flexbox.h {
  -moz-box-orient: horizontal;
  -webkit-box-orient: horizontal;
}
.flexbox > div {
  width: 30px;
  height: 30px;
  margin: auto;
}
div { border: thin solid; }

> ± Further, your examples clearly show that margins don't accomplish 
> anything ± beyond what flex-align already does, so it doesn't seem 
> like a valuable ± addition.
> ±
> ± Given the above, I'd like to keep flex-align on the flexbox items.
> ± The only downside of this is that you can't control the alignment of 
> anonymous ± items, but I don't think that's a big deal - anonymous 
> items only exist to keep ± the layout algorithm sane, not to provide 
> useful functionality that authors ± should depend on.  You can't 
> control properties of anonymous table-cells ± either, after all.
>
> I actually think applying 'flex-align' to flexbox is actually a good idea.
>
>        1) In vast majority of cases all flex items have same alignment
>        2) Exceptional cases where per-item alignment is needed are 
> easily handled with margins (as my example shows)
>        3) Alignment applies to anonymous items
>
> I realize that the above benefits are not super strong, but I don't really see what value per-item alignment brings to offset those...
>
> I think we went for per-item alignment just because we didn't realize that auto margins can be useful there. If it was a mistake we can still fix it.

If we think it's important to support both setting the alignment on the flexbox and setting the alignment on individual items, I think we should do it with two properties.  Margins are inconsistent (they only work in the cross axis), are different from block margins (the cross axis may be vertical), and complicate the layout algorithm (if a cross-axis margin is auto, it operates at a different stage than non-auto margins).

Something like flex-align (applies to flexbox) and flex-item-align (applies to items).  When aligning an item, if flex-item-align is auto, it instead consults the parent's flex-align.

~TJ

Received on Monday, 12 December 2011 23:44:36 UTC