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

"Andrew Fedoniouk" <news@terrainformatica.com> wrote:
[re '1*' not being a DIMENSION]
> Existing syntax just needs these two updates:
> 
> PERCENTAGE	::=	num '%'
> FLEX	                ::=	num '*'
> 
> any        : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING | FLEX
>               | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
>               | FUNCTION S* any* ')' | DASHMATCH | '(' S* any* ')'
>               | '[' S* any* ']' ] S*;
> 
> I do not see any problems with this, do you?

You're proposing a change in the CSS2.1 generic syntax.  I don't
think that's worth doing just for the (arguable) additional
readability of '1*' over '1fl'.

> > I have no strong opinion on any of the rest of what you say,
> > although I think that it would be better to arrange things so flex
> > units can participate in calc expressions, than to introduce a new
> > function.
> 
> Full form of flex unit value is a triple of flex-strength, min and max
> constraints. Additive flexes have one more "preferred" value so it 
> is a quadruple. I do not see any sense of trying to fit flexes inside
> the calc() while anyway you know that you will need full form at 
> some point. E.g. you may wish to define something like
>  border-spacing: flex(*, 0, 10px) 
> to implement  box-pack:justify in more configurable fashion
> then you have in XUL at the moment.

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.

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.

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

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():
  calc(10px + 1fl - shrink(10px)) :== \hspace{10px plus1fil minus10px}

And for symmetry, let's also have stretch(), which lets us do this:

  calc(10px + stretch(20px)) :== \hspace{10px plus20px}

(i.e. "this can be anywhere between 10px and 30px wide").

Is anything missing?  I find this notation much more pleasant than your
proposal, under which I have to remember the order of arguments to
flex().

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

zw

Received on Thursday, 27 May 2010 16:21:21 UTC