- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 30 Apr 2010 18:19:47 -0700
- To: Alex Mogilevsky <alexmog@microsoft.com>
- Cc: www-style list <www-style@w3.org>
On Thu, Apr 29, 2010 at 5:08 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote: >> 2. `box-align: stretch` does not allow sufficient control over the alignment of the box contents after the height is increased. I guess the children just act like normal boxes, and top-align themselves? >> This prevents us from, say, baseline-aligning boxes but still wanting a background/border to be the same height on everything. I suggest that either 'stretch' should be a valid value *in addition to* the other values, or that we should define vertical-align affecting flexbox children similarly to how it affects table cells. > > This seems similar to table alignment issue that David was showing at F2F. mixing stretch with other alignment values would complicate the model though... is there a convincing enough use case to justify it? While I'm not sure if the specific possible solution I tendered (vertical-align on children) is right, the general use-case of both doing box-align:stretch and then aligning children within their box is, I believe, valuable. For example, an effect I've seen a few times in websites, and brought up when we were discussing transitions earlier, is a horizontal navbar where the actual text within each box starts at the top, and moves down to the bottom when you hover it. I'd like to be able to handle this as a flexbox, preferably; it's actually impossible to implement in plain css + transitions since it requires absposing right now, or flexible padding. (Directly flexing width/height/padding/margin is actually a possible alternate approach to Flexbox that me and dbaron discussed the other day. I'll be writing up what we discussed next week.) ~TJ
Received on Saturday, 1 May 2010 01:20:39 UTC