Re: auto units versus 'auto' value

Hi, Lachlan, thanks for your comments,

>    As a concept, it seems reasonable to want a method that can calculate
> a length based on the /free space/ available (either vertically or
> horizontally) however, the proposal you have given for %% units, has
> some serious problems.
>    Firstly, you wrote in a previous post [1] that it would make no sense
> to apply the units to the positioning proerties, 'top', 'right',
> 'bottom' and 'left', but if a unit is defined correctly, then I see no
> reason why it shouldn't apply to those.

Let's say I am not yet sure about 'top', 'right', 'bottom' and 'left'.

Initially %% idea was to position elements in normal flow.

I can see so far how %% units will be applied to entities having 'space'
margin, width, padding, etc. Values of these attributes can participate in
free space
In contrary, attributes 'top', 'right', 'bottom' and 'left' measure
coordinates or offsets - therefore out of scope of %% units.
It is my guess. I'll honestly appreciate if somebody will propose
interpretation of the units for 'top' and 'left'.

As far as I understand "free space" is not applicable for absolutely
positioned elements. No?

This is why, I guess, 'top', 'right', 'bottom' and 'left' have no 'auto'
value currently.

> Secondly, you make the assumption [2] that whenever the units are
> used, then the sum should be normalised to be no more than 100% of the
> free space, whereas the author may actually want the sum to be exactly
> what was given.  (correct me if I've misunderstood this)

Not so. Correct statement is:
"whenever the units are used, then the sum should be normalised to be *not
than 100% of the free space"

This 'not less'  is key point here as it implies the following:

'Free space' can be 'underdistributed' (some portion of  'free space' can be
left empty)
 but cannot be 'overdistributed' (no one %% value in children shall force
changing of containers space).

Therefore in your example below each 'col' will take width value
equal to 60/180*container-inner-width. What is exactly
Constraint col:first-child { width: 100px; } will be taken in consideartion
at first step - calculation of free space.

Andrew Fedoniouk.

> eg.
> the elements to make three columns are:
> <container>
>    <col/><col/><col/>
> </container>
> with the style:
> container { display: block; }
> col:first-child { width: 100px; }
> col { width: 60%%; float: left; }
>    The last two cols should add up to 120% of the free space, however,
> if I've understood correctly (and haven't become totally confused), your
> current proposal would mean that each element would only get 50% of the
> free space.  If the calculations do add up to be more than 100% of the
> free space, then it should just overflow using the normal overflow rules.
> [1]
> [2]
> --
> Lachlan Hunt

Received on Saturday, 22 May 2004 14:44:56 UTC