# Re: auto units versus 'auto' value

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 25 May 2004 17:57:45 -0700
Message-ID: <004c01c442bc\$7574a4c0\$1902000a@AFedoniouk>
To: "Krzysztof Maczynski" <chris___m@hotmail.com>, <www-style@w3.org>
```
Hi, Chris,

Arbitrary property having %% value calculates using:

pixels = free-space-pixels * value%% / max(100, total%%)

This rule covers your if* cases I guess.

If you want your %% behave as percents use total sum in range 1..99;
If you want to have only 'weights' use total sum > 100 by using values
100...INF(inity) ;

"it seems reasonable to cause overflow"

I don't think that this is feasible at all. If we will add e.g. 'intrinsic'
value then overflow will cause recursion in  computations.  Same problem
exists with old plain percents.
Example:

<div style="width:intrinsic">
<div style="width:120%" >
</div>

To compute intrinsic value of the container you shall compute first width of
its content.

BTW: This is a fundamental problem of 'intrinsic' value and percent units.

Andrew Fedoniouk.
http://terrainformatica.com

>
> > Not so. Correct statement is:
> > "whenever the units are used, then the sum should be normalised to be
*not
> > less*
> > than 100% of the free space"
> I think this is what Lachlan meant but it seems different due to a
language ambiguity.
>
> However, it seems reasonable to cause overflow in case of sum exceeding
100*
> as he suggests. It doesn't change the box size, contrary to what you
suppose:
> > (no one %% value in children shall force
> > changing of containers space)
> If there are compelling use cases for your interpretation, a property
> (in the spirit of box-sizing) can be added with a name, say
> free-space-normalize and possible values:
> never (the default), if-more-than-100 (Fedoniouk),
> if-less-than-100, always. The latter 2 would have no effect
> if there were a competing property with value auto
> (not keyword! see my previous post).
>
> Chris M.
>
```
Received on Tuesday, 25 May 2004 21:00:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:13 UTC