Re: [flex-units] unit abbreviations and the flex()

On Thu, May 27, 2010 at 5:37 PM, Zack Weinberg <zweinberg@mozilla.com> wrote:
> "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> Zack Weinberg <zweinberg@mozilla.com> wrote:
>> > ... What I understand is TeX's glue, which looks like this:
>> >
>> >  \hspace{10px plus 1fil minus 10px}
>> >
>> > That means: try to make the horizontal space here 10px wide, but if
>> > that won't work, it can be shrunk down to 10px-10px (i.e. 0) or
>> > stretched without limit.
>>
>> That'd be expressed as calc(10px + 1fl).  (For the more common case of
>> something starting at its intrinsic width, I want to add a shorthand
>> so you don't have to write out the full calc() expression.)
>
> I see how this works in your proposal, and also how max(10px, 1fl)
> manages to do what you say, but I don't like it.  I think people are
> going to be very confused if calc(10px + 1fl) can produce a used-value
> of less than 10px, and I think the behavior of max/min is even more
> confusing.  (You yourself say it's confusing!)

Really?  I don't think that the calc() case is confusing, but it may
just be because I've stared at it for long enough.  A flex unit can
resolve to a negative length if there is negative free space.  The
result, then, is a length less than 10px.


>> If you use min()/max() to set up maximum/minimum sizes instead, then
>> there's no conflict.  calc() just does what you want.
>
> To reiterate that I *don't* want calc(10px + 1fl) to be equivalent to
> \hspace{10px plus1fil minus10px}.  That's just too much magic.

It's only magic because your idea of the "simple" case is trained by a
system with different assumptions.  When I hear you say "calc(10px +
1fl) should only go from 10px to infinity", I think "Where'd that
minimum constraint magically come from?".  ^_^


>> > As I said to Tab some time ago, negative flex *per se* is not a
>> > problem.  It just makes stuff overlap, the same way negative
>> > margins do now.  \hspace{0px minus1fil} is a perfectly legitimate
>> > thing to write in TeX and would be useful in CSS under the same
>> > conditions (you want to paint something of uncertain width on top
>> > of whatever was on that side of it).
>>
>> I don't think that a negative flex value is useful.  The naive way to
>> have it interact with other flexes would do something very bad, and
>> I'm not sure of how to do it in any consistent, intelligent way.
>>
>> But I've already answered Andrew on that - negative flexes can just be
>> treated as 0fl.
>
> I guess I'm fine with negative computed flexes being treated as 0fl
> (is 0fl meaningfully different from 0px?  I hope not) but could you
> elaborate on "would do something very bad"?

Sure!  Say you had a flexbox with a single child, and that child had
margin-left:1fl and margin-right:-1fl.  Now, assume that there is
100px of free space.  The naive way to do so is to just sum the
flexes, and then distribute (free space * flex amount / total flex) to
each flexible length.  But that would give you a division by zero,
since 1-1=0.

Ok, so maybe the absolute value of the flexes is what you should sum.
Then the margin-left gets (100px * 1 / 2), or 50px of space, and the
margin-right similarly gets -50px of space.  Now we've done something
weird, though - we didn't actually use up the free space at all.
Instead the child box's left edge is 50px from the parent's left edge,
and the right edge is 50px past the parent's right edge (unless it's
overconstrained, of course).  While I suppose that at least does
something unambiguous, it's pretty weird to me that the negative flex
reduces the space that the positive is allowed to use even though the
negative one doesn't actually *use* any space.

The final alternative is to do something like what TeX does, and have
positive flexes and negative flexes operate separately.  If there's
free space, resolve the positive flexes.  If there's overflow, resolve
the negative flexes.  That'd require a bit of a change to my model,
plus further syntax support, but I won't discard it yet.


> The experience over in
> TeX land is that infinite shrink is not a problem, and is occasionally
> useful -- for instance, in plain TeX you center a line with (a macro
> that expands to)
>
> \hss{} stuff to center \hss{}
>
> where \hss expands to, iirc, \hspace{0pt plus1fil minus1fil}.  The
> infinite negative shrink allows the centered line to extend into the
> margins of the page if necesary; the HTML/CSS equivalent would be
> allowing the centered box to overflow, by equal amounts on either side,
> if the containing box is too small.

Actually, that should work fine in Flexbox as exists.  I always
overlook that margins can take negative lengths, so I need to rewrite
my algo slightly for finding all the flex tuples so it doesn't default
the minimum size to 0 for margins.  But if there is a single box with
both margins flexible, and it overflows, both margins will shrink to
negative and will pull the box out of its parent while keeping it
centered.

~TJ

Received on Friday, 28 May 2010 19:04:05 UTC