Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox Module

On Tue, May 11, 2010 at 10:32 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> Are you working on a new draft so what we can see proposed changes in a complete document?

At the moment I'm taking a class, but I expect to publish a first
draft by Friday.


>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>> Sent: Tuesday, May 11, 2010 9:24 AM
>>
>> I would like an easier way to trigger additive flex than using calc(), though.
>> That feels somewhat cumbersome, though I value the simplicity of the
>> model as a whole more than simplifying this case.
>
> The current model allows easy switch from additive to absolute - by using "width:0". If it doesn't produce absolute flex in all implementations, it should. The spec is pretty clear about it I think.

Is width:0 a more intuitive mechanism to switch from additive to
absolute than a calc() expression would be to switch from absolute to
additive?

Personally, width:0 to trigger absolute flexing feels like a hack.  It
is somewhat unclear how it interacts with min-width as well.


>> 'start'    : margin-bottom: 1fl;
>> 'end'      : margin-top: 1fl;
>> 'center'   : margin-top: 1fl; margin-bottom: 1fl;
>> 'stretch'  : height: 1fl;
>> 'baseline' : (no mapping, use vertical-align instead)
>
> All of the above will work exactly same with 'auto'. I understand there can be some cool use of 'flex' unit, and it is more or less clear how to add it to box model (where it would then belong). I don't think box model is broken enough to fix it this way though...

We actually can't add flex units to normal flow (which is what I
assume you mean) - they'd cause iterative or incorrect layout in
common cases.


>> Box-align misses some cases, too.  For example, one can't make the box
>> stretch and then align the contents to the bottom of the box.  With this
>> model, though, that's a simple application of padding-top:1fl.
>
> Actually, if padding:auto worked, it would work here and in many other case, and finally it would allow vertical alignment without "dispay:table-cell" (which btw would make you this case work)

Note that 'auto' values for width/height/margin should work as
expected here - the sizing algo will specify how to map 'auto' values
into flex values.


>> Similarly, box-pack maps to simple and intuitive applications of flex units.  The
>> one exception is box-pack:justify, which is somewhat
>> complex:
>>
>> flexbox > * { margin-left: 1fl; margin-right: 1fl; margin-break: discard; }
>> flexbox > :first-child { margin-left: 0; } flexbox > :last-child { margin-right: 0; }
>
> Can we please keep box-pack? A lot can be done with a minimal set of powerful tools, but this is a language, it doesn't need to be minimal, it needs to be understandable. Lack of <center> equivalent in CSS is hard enough for people to understand, IMO we shouldn't go beyond that with margin magic.

Actually, <center> is trivial in Flexbox.

Old draft: "center { display: box; box-orient: vertical; box-align: center; }".
New proposal: "center { display: flexbox; flexbox-begin: top; margin: 1fl; }".

Now, addressing your objection directly, I agree.  It's more important
to be understandable than to be minimal and theoretically ideal.  But
I think that box-pack:justify is the *only* wart in transitioning to
flex units.  Every other value is trivial to implement and makes sense
as an author:

box-pack: start  ->  box { margin-right: 1fl; }
box-pack: end    ->  box { margin-left: 1fl; }
box-pack: center ->  box { margin-right: 1fl; margin-left: 1fl; }

In addition, there are plenty of things that you can't do with
box-pack without inventing new values, but you can do pretty easily
with flex units.  For example, a horizontal navbar with the items
spaced out fairly equally and not pressed against the edges would just
be:

box { display: flexbox; }
box > * { margin: 0 1fl; } /* Margins will collapse in the new draft */

You can fake this in the current draft by doing box-pack:justify and
setting some side-padding on the container, but that won't shrink or
grow with the window.


>> box-orientation: vertical     ->  box-begin: top
>> box-orientation: horizontal   ->  box-begin: left
>> box-orientation: inline-axis  ->  box-begin: start
>> box-orientation: block-axis   ->  box-begin: before
>
> You also could have adopted writing-mode abreviations (like 'lr-tb'). That can be extended to include 'se-ba' (start-end/before-after). It still sounds more scientific than intuitive (although admittedly cool).

I had considered that, but decided against it.  ^_^

~TJ

Received on Tuesday, 11 May 2010 20:56:49 UTC