Re: Proposal: content-vertical-alignment

----- Original Message ----- 
From: "Laurens Holst" <lholst@students.cs.uu.nl>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <www-style@w3.org>
Sent: Tuesday, June 14, 2005 2:54 PM
Subject: Re: Proposal: content-vertical-alignment


>> Auto value for margins also means exactly: 100%%
>>
>> |<-100%%-><-- width:100px--><-100%%->|
>
>
> No they don’t, that amounts to 200%, which means the element will be twice 
> the width of its parent container.

No. Behavior is exactly as current behavior in tables. Try to put
two columns having width set to 100% each.
Total sum of %% or 100 whicever is greater
is used as a cap in computation.
Please read my formal definition of %% units in previous post.
(or http://www.terrainformatica.com/htmlayout/fspu.whtm)

>
> In case you think I’m wrong here, then your earlier example where two 
> elements with a width which don’t sum up to 100 leaving free space (e.g. 
> 20%% + 50%% leaves 30%% undistributed) doesn’t make sense.

This give us flexibility. %%s can serve as both - percents and weights.

>
>
> Andrew Fedoniouk wrote:
>
>> Yes, inline elements do not have width/height by definition.
>> But inline-block and inline-table do have dimensions.
>
> Which happen to be supported by none of the major browsers (so I’d say get 
> those implemented first, hehe).

You knowledge is outdated. IE supports inline-blocks since 6.0.
(only for naturally inlined elements like SPAN but nevertheless).

>
> Anyways, but that’s kinda nasty - if the content gets resized to a size 
> smaller than the smallest specified width (or the rest of the content, 
> e.g. text, gets too big to fit on one line), then no horizontal scrollbar 
> appears, but instead the elements will flow into the next line and the 
> layout totally messes up.

There is a white-space:nowrap for such cases as you may know.

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

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

>
> Besides, in the XUL box model Mozilla implements there is already 
> something from my perspective does exactly the same, but then 
> better: -moz-box-flex.

Probably. I never heard proposals about it in the list and nowhere.

>
> I’d like to note by the way that with the existing model %% of course 
> already applies to block heights (e.g. 
> body{height:100%}#a{height:30%%}#b{height70%%}), but if it’s just that it’s 
> pretty limited, I can’t really see a common situation where I would need 
> that and where absolute positioning (possibly combined with calc()) wouldn’t 
> already do exactly what I want.

And what do you want exactly?

>
>>>
>>> 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.
>
> I agree that calc is more fragile (OTOH, in the case you mentioned, I 
> think it is not, you can use em font sizes and such). However, calc() is 
> something which applies much more generally and solves many issues, and in 
> most cases it will do what people need. I also think that something more 
> fragile than most existing CSS on the web, with faux columns and floats 
> used for everything that’s loose, is just impossible, so it can’t be that 
> bad :). Also, constants would alleviate much of the remaining issues, I 
> think.

What issue solves calc?

>
>> 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.
>
> I think calc() can do pretty much that - the only downside is that sizes 
> have to be specified twice, once in the original width and once in the 
> calc(), which introduces a maintainability problem (hence my suggestion 
> for constants earlier). It is certainly the most flexible way to do it. 
> Other solutions would could indeed be more of a distributive nature, where 
> the browser takes care of that math, and I understood there were thoughts 
> to create some kind of ‘grid’ layout system to do things like that. 
> However, I do not think %%, at least not in the way you currently proposed 
> it, is a good solution.

Why?

OT: There is a good principle : criticizing - propose. Only this way it is 
possible
to reach a solution.

>
>> 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.
>
> I still see many issues, no. 1 being that it only really applies to 
> inline-block (and inline-table, but you just said we wouldn’t need them 
> :)), for which the behaviour of %% is under-specified and doesn’t seem to 
> degrade well when resizing due to the intrinsic nature of inline-block 
> being part of an inline flow.

Sorry but your look is too narrow for some reasons. Try to think more on
it. Feel the Force:

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?

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

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

>

Received on Tuesday, 14 June 2005 22:57:07 UTC