Re: Proposal: content-vertical-alignment

Andrew Fedoniouk wrote:

>> I see a possibility in using %% like % + calc() in an absolutely 
>> positioned context (or a percentaged * in an old-fashioned frameset), 
>> but as you said, %% doesn’t apply there (and as I said it would be 
>> unneeded anyway, per the existence of calc()). Using inline blocks 
>> instead to achieve a similar effect using %% units then *is just 
>> wrong*. You want to lay out an element in a certain way, it’s not 
>> inline at all.
>>
>> For the actual styling of inline block content (e.g. an image), I 
>> don’t really see the need or use to introduce a special unit to be 
>> able to... stretch it to the end of the container, or for 50% of the 
>> space until the end of a container? What would that be useful for? 
>> And what if there is text after the %%-sized inline blocks? Text 
>> flows accross lines, so the minimum width is 0 (just placing it on 
>> the next line), the maximum width is something very close to ‘100%%’ 
>> as well (depending on word size and breaking).
>
> I missed you here. Seems like you are using some particular
> design pattern which is unknown to me.

Take e.g.

<body>
   text some words here...
   <div style="width: 60%%; min-width: 100px;">text</div>
   <div style="width: 40%%; min-width: 100px">text</div>
   text bladibla bludiblu
</body>

Now resize your browser. When it is wide enough for all to fit, sure, I 
understand see what happens. What if you make it smaller such that 
bludiblu doesn’t fit, and falls into the second line box. Then I wonder: 
what will happen. Will that simply be bludiblu on the next line, and the 
other text being right-aligned by the stretching divs? Because why 
shouldn’t the entire second text fall on the second line - after all, it 
doesn’t *have* an intrinsic width, the width is only determined after 
the widths of the elements before it is calculated. Which they haven’t 
been yet, because they’re depending on the width of the elements after 
them. So you’ve got two interdependancies, which to fulfill first?

What if you make it smaller such that the second div falls on the next 
line, because of the min-width. Will the first div take 100% of the 
width (the original sum, which was probably intended to make a total of 
100%), or will it only have a width of 60% now that the second div is in 
another line box?

For that matter:

<body>
   <div style="width: 98%;" />
   <div style="width: 50%%;" />
   <div style="width: 50%%;" />
   <div style="width: 98%;" />
</body>

Div 1 and 4 will be on 2 separate lines because they’re inline blocks. 
Where are the 2nd and 3rd divs? At the end of the first second line, 
both taking 1%? Before the second line, ditto? Or one on both lines, 
taking 2%%? What if the middle two divs have a min-width of 2%? Would 
they distribute over 2 lines, or ould the third div use an entire line, 
or would they ignore the min-width?

Many questions here, and even though perhaps you can think of an answer 
for each of these cases, it seems difficult to me to think of a 
catch-all algorithm for this without applying any fuzzy logic. And if 
there is one for that, it should be defined clearly.

Because *when* is an %% unit on an element calculated? The min-width 
case clearly illustrates that you can’t simply say ‘calculate %% units 
after calculating all other units’, because whether min-width is 
effective depends on the calculated width, which would then if min-width 
is bigger need to be recalculated for every %% property, etc. etc.. 
Difficult, and I wouldn’t be surprised if that could create infinite 
recalculation loops without creating a loop detection mechanism. And 
min-width is very common, even if just because many elements have a 
minimum intrinsic width.

Questions questions questions.

And I’m not even considering the fact here that allowing things to flow 
onto a second line is probably not desireable. Or that this totally 
doesn’t work for incremental rendering.

>> But flow: horizontal is not part of CSS. I think your first priority 
>> would be to get that in CSS then, before introducing %% units.
>
> You don't need them. inline-block is here. it is enough.

But it’s an inline block! It’s *inline*. The flow is totally different 
from e.g. the XUL horizontal flow.


> E.g.
>
> <div>top</div>
> <div style="margin-top:100%%">bottom</div>
>
> will position 'top' at top of the conatiner and
> 'bottom' at bottom.
>
> Do you care about reproducing such layout with calc or anything around?

You got me there :). So hey, my proposal isn’t perfect! So I’m not the 
universal source of all knowledge! (oh wait, I am! :)). I didn’t brood 
on it for years upon years, gathering kamikaze wisdom for the perfect 
solution ;p.

By the way, this very example, do it for horizontal values and tell me 
what happens when you resize the browser such that ‘top bottom’ does not 
fit on 1 line, and how the effective result (bottom on 2nd line aligned 
to the right) would in any way be what I would desire (which is that the 
browser gets a horizontal scroll bar because it just doesn’t fit). It is 
very much dependant on the content fitting in the browser window.

My main problem with this is that it only applies to inline-block, and 
that inline-block is totally unsuitable as a flow model for this. And 
that if you can’t make it apply to e.g. absolute positioning or block 
boxes or whatever model that isn’t there but we would apparantly need 
for this, then probably another solution (e.g. grid-based) would be better.

I can see how it would work in a mozilla-like box model, in fact it is 
pretty much the same except that Mozilla uses numbers instead of ‘double 
percentages’ (e.g. box-flow: 1 and box-flow: 2 is like 33%% 67%%) and 
doesn’t allow you to specify less-than-100% flex, at least not with this 
mechanism (but I do think that’s kind of useless anyway). Oh, and it 
only applies to widths and heights, of course. At least, that’s what I 
gather, I’m no expert on XUL CSS extensions :).

> :)
> Andrew Fedoniouk. Old, experienced kamikaze having
> MS in Physics and Applied Mathematics and Diploma in Arts.
> :)

Hehe ;p.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.

Received on Tuesday, 14 June 2005 23:52:00 UTC