Re: Proposal: content-vertical-alignment

----- Original Message ----- 
From: "Laurens Holst" <lholst@students.cs.uu.nl>
Subject: Re: Proposal: content-vertical-alignment

> Andrew Fedoniouk wrote:
>
>>Formal definition of %% length units:
>>When allotting space among element attributes competing for space along
>>axis, UA allot all values for attributes having other than %% lengths
>>first, then divide up remaining available space among %% lengths. Each %%
>>length receives a portion of the available free space that computed as a
>>percentage from total sum of all %% units along axis. If total sum of all
>>%% lengths along axis is less then 100 then 100%% value is used as a total
>>sum of all %% units. Thus, if 100 pixels of space are available after the
>>user agent allots pixel and percentage space, and the competing relative
>>lengths are 10%%, 20%%, and 70%%, the 10%% will be alloted to 10 pixels,
>>the 20%% will be alloted 20 pixels, and the 70%% will be alloted 70
>>pixels. If 100 pixels of space are available, and the competing relative
>>lengths are 10%%, 20%%, and 30%%, the 10%% will be alloted to 10 pixels,
>>the 20%% will be alloted 20 pixels, the 30%% will be alloted 30 pixels,
>>and remaining 40 pixels will be left undistributed.
>>
> What if a block has a width of ‘auto’? That makes it have 100% (incl.
> borders and paddings) of the width. Will this cause the width to behave
> differently (e.g. use the minimum computed width instead?).

Width 'auto' for static blocks is exactly 100%% -
it takes space left from left/right margins, paddings and borders (MPB)

|<-mpb-><-- width:100%%--><-mpb->|
-or-
|<-mpb-><-- width:auto--><-mpb->|

Auto value for margins also means exactly: 100%%

|<-100%%-><-- width:100px--><-100%%->|
which is current behavior for
|<-auto-><-- width:100px--><-auto->|

In most cases in current spec. auto value equals to 100%%.
(Other cases - where 'auto' is wrongly (imho) used for marking
intrinsic,  min-intrinsic, max-intrinsic values.)

>
> And you say this applies to all blocks in normal flow. Afaik, absolute
> positioned blocks and floats, for which this would be useful, are not part
> of normal flow, so that excludes those.

Yes. absoulutes and floats are out of normal flow and meaning
of width:auto is completely different for them from blocks in normal flow.
There is just no "free space" concept for absoulte blocks - they live
in the Universe having no borders - thus free space there is infinity.

> That leaves statically  positioned blocks, of type inline and block.
> Inline elements can’t have specific widths, so those are excluded as well.

Yes, inline elements do not have width/height by definition.
But inline-block and inline-table do have dimensions.

Take a look on screenshot:
http://www.terrainformatica.com/w3/fsputests.png
Here you may see how
http://www.terrainformatica.com/w3/fsputests.htm
behaves on different container widths.

> Thus we end up with block boxes. Block boxes however don’t stack
> horizontally (like e.g. floats do), so then what would the point be of
> having %% units?

First, see above for inline-blocks.

Second, I did test implementation of 'flow:horizontal' attribute
which allows
to reproduce VBOX and HBOX  XUL elements in CSS.
E.g. flow:horizontal being applied to the div causes all
its children in normal flow to layout from left to right (versus
current top to bottom).
This and %% units allows to implement sidebars alike layouts
more naturally:
|<-left SB -><-- contet div width:100%%--><-right SB ->|
and without any tables, sic!

>
> If this does apply to absolutely positioned blocks (which is really the
> only use case I can see), then isn’t a calc() function (e.g. width:
> calc(100% - sum-of-all-known-widths)) a better solution which in addition
> applies more generically to length units used elsewhere?

calc is not better solution at all: imagine that user have its
own CSS applied to the page increasing font sizes, etc.
This will ruin all your calcs making the whole system too fragile.

In general absolutely positioning is breaking
flexibility of HTML layout - it does not allow to implement
"this element attached to that" without scripting.
As a rule documents using abs units are rendered
extremely bad on different screen resoultions, etc.
I think this is obvious and we all know that too well.

Again, if we would have %% units then we
don't need calc at all, tables - most of current
layout cases will gone and absolute positioning will be used
only in cases where it is really needed.


Andrew Fedoniouk.
http://terrainformatica.com

Received on Tuesday, 14 June 2005 20:27:16 UTC