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

> [Original Message]
> From: Andrew Fedoniouk <news@terrainformatica.com>
> To: <ernestcline@mindspring.com>
> Cc: W3C Style List <www-style@w3.org>
> Date: 5/21/2004 8:31:54 PM
> Subject: Re: auto units versus 'auto' value, was Re: vertical-align
>
> > 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.
> >
>
> Exactly!
>
> So:
>
> <p><span width=30%% /></p>
> <p><span width=30%% /><span width=60%% /></p>
>
> in both cases width of first span will be the same. And we
> will have empty non distributed free space.
>
> we have not any problem with the "over-constrained" in this
> case. Right?

'width' does not apply to inline non-replaced elements, so in
both cases whatever the computed value of width is, it doesn't
matter. See <http://www.w3.org/TR/CSS21/visudet.html#q4>
Over -constrained occurs in the context of block elements
not inline elements. (Did you even look at the link I gave you
in my previous post?)  If you are seriously suggesting causing
'width' to apply to inline elements, I suggest you think of another
way to do what you want to do.

> And let's take a look here:
>
> <DIV style="width:30%%">...</DIV>
>
> Three choices:
> 1) If nothing else given may be treated as: this block is getting
> display:inline-block style.
> 2) If display:block then total sum of all %% is used for width
> computing.Not max(total,100).
> 3) Use the same approach as like any other fixed value set
> for this block width - use "carriage return" after.

Ugh!  This is worse that I thought it would be.
It looks like you want to replace the entire layout model with
something completely different and introduce dependencies
between properties that don't currently have them.  There
is a place for something that improves upon using just "auto"
in the layout model, so that when there are multiple automatic
values, something other than the current default results could
be specified.  As I currently understand your proposal, the
benefits certainly aren't worth the additional complexities it
creates and the problems that would be associated from
switching to a totally different layout model.  The problems
that the current model has are fairly well understood by now
and some of its  complexity results from trying to make
certain things unambiguous.  There isn't any need to scrap
the current layout model  and go with something different
just for a few minor cosmetic effects that I think could be
achieved without scrapping the current layout model.

Received on Friday, 21 May 2004 21:41:17 UTC