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

On Thu, May 27, 2010 at 9:20 AM, Zack Weinberg <zweinberg@mozilla.com> wrote:
> So I don't really understand either your "absolute flex" proposal, or
> the thing presently implemented in XUL that you call "additive flex"
> either.  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 had been under the impression that your '1*' in a CSS <length>
> was _exactly_ the same thing as writing \hspace{0px plus 1fil}.  Except
> that it can't be that simple, because you object so strenuously to what
> you call "additive" flexes, but to my mind, \hspace{10px plus 1fil} is
> a perfectly sensible thing to want ("make this no smaller than 10px,
> but it can be stretched without limit if necessary"), and
> calc(10px + 1fl) is exactly how I want to write that.  I don't care
> whether that fits into the existing semantics of calc(); those are not
> set in stone, they can be redefined so that it works the way it appears
> to work.

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

So \hspace{10px plus 1fil} is done as max(10px, 1fl).  \hspace{0px
plus 1fil} is indeed the same as just 1fl.

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.

> (Now maybe \hspace{10px plus 1fil} is not what you mean by "additive"
> but then I have no idea what you do mean - please don't bother trying
> to explain it to me, though, this is really not what I need to be
> spending time on today.)

Additive flex is equivalent to your first example - calc(10px + 1fl)
is equivalent to the TeX notation \hspace{10px plus 1fil minus 10px},
like you expressed at the top of your message.  \hspace{10px + 1fil}
is equal to max(10px, 1fl).


> We run into a bit more trouble if we want to fit shrinkage into calc()
> (and I do) because "calc(10px + 1fl - 10px)" properly ought to be
> equivalent to "calc(10px - 10px + 1fl)" and thus to "calc(0 + 1fl)" and
> the bare "1fl".  I think what's needed here is a single-argument
> function shrink(), that goes INSIDE calc():

If you use min()/max() to set up maximum/minimum sizes instead, then
there's no conflict.  calc() just does what you want.


>> In any case you will need to deal with possibility of
>> negative flexes like here
>>    calc( (10 - 10em/10%) * 1fx )
>> I do not think that Gecko as any other existing UI has
>> any room for implementing algebraic analysis of calc
>> expressions to split them on fixed and flex parts for separate
>> calculations.
>
> 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 don't want to support "(10px - 10em/10%) * 1fx", but that can be
> excluded by dimensional analysis; no need for a full-blown algebra
> engine.  (Tangentially, I feel very strongly that dimensional errors
> within calc() MUST NOT be treated as syntax errors.)

Right, that'd be a dimensional error.

~TJ

Received on Thursday, 27 May 2010 17:26:30 UTC