Re: [css3-flexbox] Trying out flex units again

On Thu, Feb 3, 2011 at 3:05 AM, Mikko Rantalainen
<mikko.rantalainen@peda.net> wrote:
>> On Wednesday, February 02, 2011 1:10 PM, Tab Atkins Jr.
>>> This is theoretically more complex, in that there are more values, but
>>> in practice it appears that authors find this simpler.  It seems to
>>> map well to how people *want* to think about flexible boxes, so they
>>> don't need to create new complexity in their mental models.
>
> Usually when a model depends on more values under the surface
> understanding it's behavior ends up being harder. The more values you
> have under the surface, the more complex interactions those values can
> do and the resulting behavior seems less intuitive.

Again, it's not safe to generalize here.  Yes, in general, more values
= more interaction = more complexity.  In the specific case here,
though, the values are all uniform; it's the same 3/5 values repeated
over and over again, not 50 distinct values, and they interactions are
precisely as complex as they would be if only width and height were
flexible.  The complexity gain is trivial, much less than one would
naively expect.


> I find current flexbox design hard in that flex() can be used to specify
> both preferred width and flex - how is this simpler than just setting
> e.g. 'width' to the sum of preferred width and requested flex: calc(10em
> + 1.2fl)? This way, negative flex does work exactly the same: calc(10em
> - 0.2fl). I'd expect authors to have to learn about calc() in any case
> because it has other uses in addition to flexbox. Not having to learn
> about flex(), too, would be easier for authors.

Using calc() for this was claimed to be unintuitive last time I tried
that.  I'm somewhat inclined to agree.  More importantly, you can't
get a length to have both positive and negative flexibility without
inventing magical syntax for calc(), at which point you should just do
a separate function instead.

> I understand that flex() function allows having different flex settings
> for shrinking and growing. I'm not at all convinced that the additional
> complexity that this raises is worth the (still unknown to me) use cases
> that this feature allows.

I am strongly convinced of the necessity of different positive and
negative flexibility now.  It was raised as a strong concern in my
earlier drafts, and examples were brought up during the Oslo ftf last
spring showing how forcing the two flexibilities to be equal produces
bad results.  In general, boxes with higher flex will be wider, in the
common case of available free space.  When you flip into a
space-constrained situation, though, suddenly the high-flex boxes
become *smaller* than the other boxes, which is very surprising.
There doesn't seem to be a natural way to automatically reinterpret
flexibility to keep the "high flex = bigger" motif, either.

Plus, the TeX model of flex has separate notions of positive and
negative flexibility, and puts it to great use.  I read the relevant
parts of the TeXbook recently, and there are many examples where
having the notions separate is very useful.


> I believe that separating the display model and flow (layout) would be
> beneficial. I find Andrew's design a bit simpler (as much as I
> understand it) and he seems to be able to do it with less features added
> to current CSS specification.
>
> Perhaps all that we need is some kind of mapping from latest flexbox
> spec to Andrews design. Then we can get all people speaking about the
> same thing, hopefully. It currently seems to me that Andrew's design has
> not been considered fully because some details are lacking (Andrew
> understands those details, nobody else does).

I agree that splitting out the various concepts currently bashed
together in the 'display' property is sensical.  I don't agree with
Andrew's particular method of separating them.  For example, I can't
imagine what a "flow:radial; display:table;" layout would even look
like - tables and pie menus have two fundamentally different methods
of laying out descendants.  The two notions should be in the same
category (layout managers) and be mutually exclusive on a single
element.

~TJ

Received on Thursday, 3 February 2011 18:47:44 UTC