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

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

Trust me, I know it. Just think about it as 
<span style="display:inline-block; width=30%%" />
Sorry, I used schematic representation. 
As you probably know there no such entity as width attribute in <span>

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

I gave choice 3) which is not changing anything.

>.... introduce dependencies between properties that 
> don't currently have them.

I am sure you already know such dependencies as you already mentioned 
width style property computation of which depends from 'display' value.

Andrew Fedoniouk.
http://terrainformatica.com.

Received on Friday, 21 May 2004 23:25:04 UTC