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

"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!)

I think people would rather have the mental model that '+1fl' goes up
to infinity and down to zero, but does *not* go negative.  Then 
calc(10px + 1fl) does what I said it did.  The price is that max() and
min() including flexes doesn't do anything especially useful (which I
think is fine) and we need some other notation for "flex down" (hence
my suggestion of shrink()).

> Not quite.  The calc() syntax lets you set up a "preferred size" for
> the length, which can then be flexed larger (if there is free space)
> or smaller (if there is negative free space, and the flexbox would
> otherwise overflow) - if you want a minimum size you can either use
> min-width/height, or the max() function for padding/border/margins.
> (Yes, I meant max() to set up a minimum size.  The mismatch between
> language and function is confusing, but can't be helped.)

I'd do the "preferred length but some shrinkage allowed" case with
shrink() -- actually, perhaps "upto" is clearer than "shrink"...

  calc(10px + 1fl - upto(10px)) // 0 to infinity, prefer 10px

> One disadvantage of this is that you have to nest 3 functions if you
> want to specify a flexible length with an explicit minimum, maximum,
> and preferred size, like "max(10px, min(50%, calc(1fl + 50px)))".  I
> suspect this to be a rare situation, though, and so I suspect it's
> probably not worth optimizing for.  If I were to support it, though,
> I'd do so with a somewhat more appropriate syntax than a simple
> function with multiple arguments - flex(1fl + 50px min 10px max 50%)
> would probably work.

This would then be calc(50px + upto(50% - 50px) - upto(40px)).

... Now I'm looking at that, it's not ideal, either.  The trouble
(borrowed from TeX, I guess) is that in a lot of cases (like this one)
one would rather specify min/max/preferred all as absolutes, rather
than min/max relative to preferred.  Maybe that is worth inventing a
new notation for, something like

  calc(10px ... 50px ... 50%)  // min, pref, max
  calc(10px ... 50px) // min = pref, max

(I think the other alternative for two arguments -- "min, max = pref"
-- will be rare enough that it's ok to have to write it out explicitly.
The ... operator has the lowest possible precedence, and all other
operators distribute over it if you force that with parentheses.)

> 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.

> > 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"?  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.

zw

Received on Friday, 28 May 2010 00:38:33 UTC