W3C home > Mailing lists > Public > www-style@w3.org > May 2004

Re: auto units versus 'auto' value, was Re: vertical-align

From: Ernest Cline <ernestcline@mindspring.com>
Date: Fri, 21 May 2004 19:13:22 -0400
Message-ID: <410-220045521231322109@mindspring.com>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "W3C Style List" <www-style@w3.org>


> [Original Message]
> From: Andrew Fedoniouk <news@terrainformatica.com>
>
> The main idea of %% is exactly to solve "amorphity" of 'auto' in places
> where it used as a width of free space.
>
> See, in cursor: it means exactly 'any'.
> In <div style="margin:auto"> it means for some reasons 50% from
> free space in inner box of container.

That is because {margin:auto} is equivalent to
{margin-left:auto;
 margin-right:auto;
 margin-top:auto;
 margin-bottom:auto}

When both margin-left and margin-right are set to "auto"

> In <div style="margin-left:auto"> it means 100% from free space.

Because you have set only margin-left to auto so it is the
only margin that gets the free space.

> Personally I think that instead of 'auto' in widths/heights, margins,
> paddings, borders is better (more strict if you wish) to express your
> intention this way:
>
> div style="margin:50%%"
>
> or even
>
> div style="margin-left:25%%; margin-right:75%%"
>
> why not?  it is not changing anything in principle!

It is a more flexible version of auto.

> E.g. default blockquote layout behavior is better to define as:
>
> BLOCKQUOTE {
>     padding-left:20px;
>     padding-right:20px;
>     width:100%%; /* rest of what left from paddings margins etc. */
> }
>
> as it strictly defines what is going on. Versus current fuzzy width:auto
> definition.

Not fuzzy at all.  width:auto is equivalent to what you call
width:100%%. (assuming that there are no other %%'s
bedeviling it.)

> >
> > You've effectively defined '%%' as a specialized <length>.
>
> Beg my pardon if I was not clear enough somewhere.
>
> I am positioning %% on the same level as <length> and
> <precentage>. Not inside any of them.
> As 'auto' does not belongs to <length> nor <percentage>.
>
> <length> | <percentage> | <percentage-from-free-space>

But it is only used where <length> is used, but not in every
place that <length>is used.  That is why I called it a
specialized <length>

> > Personally, if such a construct is defined in CSS I would
> > prefer that it use a unit of '*' because of the analogy with
> > HTML multilengths. and the idea that if the sum of the %%'s
> > is always defined to be the greater of 100 or the actual sum
> > is a ludicrous idea in my opinion.
> >
>
> If this max(100,totalsum) gives you flexibility to say "i want this to be
> 50% from free space and rest I want to be unoccupied" then why not?

If the sum of the %%'s was always taken to be 100, then to convert
a computed value of 30%% to an actual value, one would

1. Determine the amount of free space.
2. Multiply the amount from step 1 by 30
3. Divide the amount from step 2 by 100.

If the sum of the %% was always taken to be the actual sum, then
to convert a computed value of 30%% to an actual value, one would

1. Determine the amount of free space
2  Multiply the amount from step 1 by 30.
3. Determine the sum of the %%'s
4. Divide the amount from step 2 by the amount from step 3.

Your method is:

1. Determine the amount of free space
2  Multiply the amount from step 1 by 30.
3. Determine the sum of the %%'s
4. Determine the greater of 100 and the amount from step 3.
5  Divide the amount from step 2 by the amount from step 4.

Whenever the sum of the %%'s is not truly 100%%,
and one takes it to be 100%%, the result is an
over-constrained equation [1]

If you don't want over-constrained equations to be a result
of using %%, then one must always use the actual sum
of the %%'s

If you want over-constrained equations to be a possible
result from using %%, Then using 100%% as the "sum"
all of the time is more efficient and allows you to generate
any layout that your method does.

[1] http://www.w3.org/TR/CSS21/visudet.html#blockwidth
Received on Friday, 21 May 2004 19:13:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:30 GMT