- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 21 Dec 2010 14:39:36 -0800
- To: Alex Mogilevsky <alexmog@microsoft.com>
- Cc: www-style list <www-style@w3.org>
On Tue, Dec 21, 2010 at 2:04 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote: > Well, right, you can also get the same effect as " align+margin reduced" with auto padding (or almost same)... > > As I recall the biggest issue with flex-align is that in many cases it seems that it is there only for baseline. If it weren't, margins could just be enough. Yup, baseline is the problem. Without that I could get away entirely with just using flexible margins and paddings. > I see a few ways to go about it: > > 1) admit it is about baseline and call it "flex-baseline-align:none|baseline". That handles most cases via margins, and does extra just for baseline Hm, that's a definite possibility. It then becomes more like flex-pack, where it's just intended for the valuable corner-cases that you can't easily get with flex units (/ auto values, which are all we need). As well, this removes any direction-dependence, so I don't have to reuse the logical keywords for incorrect purposes here. > 2) use vertical-align (we've discussed that one, right) -- just make it apply to flex items too, with same meaning as for table cells (or similar, if not everything about table cells makes sense to apply). This is a possibility, but I'm loathe to re-use vertical-align. Using it for table cells in the first place was a mistake, because it radically changes the meaning of the property. Further, its values are very badly named for flexbox, where "top" can mean top, left, or right, depending on the flexbox direction and the writing direction. > 3) take "align+margin" as is, it is fine that some outcomes are similar, as long as it is clear that they do. Anything more intuitive than "vertical-align:text-top" I would find reasonable. Also still on the table, though I'm slightly afraid of specifying it. There will be a lot of temporary lengths that get used in the computation of more temporary lengths, before I can finally actually figure out how much free space there is. > I am not sure BTW what "[anything]" means in the new column. Is it one of before/middle/after/baseline, and regardless of value the effect is the same? But that wouldn't do 2/3/7, would it? Yes, [anything] means it doesn't matter. Under that model, auto margins get first crack at free space. flex-align gets the scraps left over at the end, just like flex-pack. > Ah, actually wait a minute... pictures 4, 5, and 10 are wrong. There is no reason to stretch the box when there is an auto margin and no baseline alignment. You should have same picture for 1=4=5 and 10=12=13. And 6=8=9. You're right that not stretching the box up/down is a possibility. That may be better, I dunno. 1, 4, and 5 shouldn't be the same, nor the other ones. The point for each is that *first* the contents are aligned as specified by the second argument, then *second* the boxes as a unit are aligned as specified by the first argument. ~TJ
Received on Tuesday, 21 December 2010 22:40:28 UTC