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

On Mon, May 10, 2010 at 11:22 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
>It seems clear that there will be a new model there eventually, when it is it better be in sync with flexbox. We should discuss that in next F2F and ideally have at least some idea on where all of the above are moving.

Indeed, that's the plan.  I'll definitely want to discuss all this in August.


> •       I *really* don’t like the attempt to switch from additive (flex values distribute the extra space after STF sizes are calculated) to absolute (no STF, flex distributes all space). I see it discussed, but I can’t track where exactly it was proposed, if it was… Additive nature of flex is the most elegant part of the design IMO.

Opinions vary quite a lot on this, it seems.  I've had several people
say that absolute flex makes more sense.  IMO, while I see the value
in additive flex, I think it's usually an edge case, and people will
often want absolute flex instead.

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.


> •       Also it appears flex becomes a “flex unit” and applies to more stuff, like margins (I also see it mentioned but don't see where it is proposed). It sounds like added complexity which would need to be justified.

These things were proposed in conversation with dbaron and fantasai.  ^_^

The justification, though, is pretty simple: I think that tying the
flexing into a known system (specifying lengths for
size/padding/margin) makes the system as a whole easier to understand
and author.  We already ask authors to use flexes implicitly in those
properties via the "auto" value - auto width causes the width to flex,
and auto margins flex as well.  The current box-align property, for
example, maps as follows (assuming a horizontal flexbox):

'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)

I think that the latter mappings are *extremely* intuitive and simple
to understand - they're exactly what an author would try to write by
themselves as soon as they learned what flex units are.  Reusing the
existing mental architecture like this is a win when one can pull it
off.

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.

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; }

However, once again there are multiple cases missed by box-pack that
are useful to authors, and easy to specify in pure flex units.

Finally, introducing flex units here makes it easy to then introduce
them to other layout modes when they make sense.  It's been
established that adding flex units to normal flow is a non-starter.
But using them in absolute positioning is very easy and intuitive.
Frex, the canonical "how do I center a box vertically and
horizontally" can be done with "box { position: absolute; top: 1fl;
bottom: 1fl; left: 1fl; right: 1fl; }", which again is one of those
things that just makes *sense* once you learn what flex units are. [1]

> •       Replacing box-direction and box-orient with flexbox-begin I don’t like. It doesn’t make it more intuitive; it may be more elegant and solve reverse orthogonal direction problem, but I think that last problem would be better solved with an extra property. "begin" property may even match internals of a reasonable implementation better, but in API simple things should be simple. I would much rather see something like this:
>
> -- flexbox-orientation: horizontal | vertical | inline-axis | block-axis (fully-spelled 'orientation' is better than 'orient')
> -- flexbox-direction: normal | reverse
> -- flexbox-align-direction: normal | reverse (a new property to control orthogonal direction)
>
> "orientation" should be the most used property. "direction" and "align-direction" will be used sparingly, and shouldn't distract from the most common use case.

Ah, I think I see part of the problem - I forgot to explain that
box-begin can take a single value and then intelligently sets the
second value appropriately.

I agree that box-orientation is usually going to be all that you need,
but check out what those values map to:

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

I think that these are equivalent in terms of easy authoring and
understanding.  (Well, start/before are still sort of weird, but
that's a cost we just have to swallow for logical directions.)  The
latter is a lot shorter, though.  ^_^

Then, though, in the rare cases you do need to control it more
closely, I think box-begin is a clear winner.  Frex, making a
horizontal flexbox that stacks new lines above is just "box-begin:
left bottom" in mine, but "box-orientation: horizontal;
box-align-direction: reverse;" in yours.  That's not only
extra-verbose, but requires an additional layer of mental abstraction
remembering what the "normal" way of aligning is, so you can reverse
it.

~TJ

[1]  I think this is easier than the currently-existing method for
centering an abspos element horizontally:
box {
  position: absolute;
  left: 0;
  right: 0;
  display: table; /* or width:fit-content, once that's supported */
  margin: 0 auto;
}
...which, though it draws on existing knowledge of how to center
things with auto margins, relies on the somewhat-unintuitive fact that
left/right position the edges of the *margin box*, and so you can then
flex the margins within that to get the border-box to center itself.

Received on Tuesday, 11 May 2010 16:25:19 UTC