Re: Proposal: %% units (was: content-vertical-alignment)

I think your %% units might be very useful in many cases. I clearly saw 
the usefulness once you mentioned the equivalence to "auto":

	100%% = auto

....for block widths, margins, etc. Therefore,

	50%% = 0.5 * auto

....etc.

How does this relate to situations where more than one %% measurement 
is being cut from the same free space, totaling greater than 100% of 
the free space? Your proposal clearly describes what happens if less 
than 100% is allocated, but it unclear about this situation:

	|<---------- width:500px---------->|
	|<-75%%-><-- width:100px--><-75%%->|

Would 75%% = 300px each (pushing the right boundary wider than the 
defined edge), or 75%% = 150px each (leaving 100px unaccounted for)?

Also, are values greater than 100%% allowed in any single declaration?

I think this issue might be resolved by being more clear as to when the 
calculated value of available space happens; include in this how it 
becomes re-calculated during window sizing.

I think the %% unit is more useful than calc() in many circumstances -- 
for example, especially when working with large teams or when otherwise 
declaring styles that may be incomplete (e.g., other styles are 
provided by the user, or some outside content provider). This can be 
remedied in the calc() proposals by having a keyword that represented 
the available free space -- perhaps "auto" itself, to show the 
comparison and to avoid "*", which was used in the MultiLength spec but 
would be confused with the multiplication symbol in calculations.

The strongest aspect of the %% units is that they do not assume sole 
authorship of the final style; this is the greatest weakness of the 
calc() proposals I've seen. (It is also a significant weakness in many 
of the more complex proposals, the multi-image backgrounds being one 
that comes to mind.) However, %% seem singularly applicable, while 
calc() solves many problems with a single rule.

Also, I take issue with this:

> 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 do not think it is an either-or argument, although I am leery of 
adding redundancy to the spec. I suspect calc() would need to be used 
in some cases still. I can imagine a min-width applied to a paragraph 
next to a floated image (so that the image doesn't crush the paragraph 
into a vertical column of letters).

img { float:left; margin:1em 1em 1em 0; width:120px; }
p { width:75%%; min-width:calc(120px + 1em + 10em); }

<img src="bio_pic.jpg" height="220" width="120" alt="" />
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. ... </p>


If anything, this argues for a single, solid calc() spec that can be 
used for your %% purposes, since I do not think %% can be used for all 
calc() purposes.

-- 

	Ben Curtis : webwright
	bivia : a personal web studio
	http://www.bivia.com
	v: (818) 507-6613

Received on Tuesday, 14 June 2005 22:39:56 UTC