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.

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.


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

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.

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

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

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.

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.

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

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

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


~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 21:54:41 UTC