W3C home > Mailing lists > Public > www-style@w3.org > June 2005

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

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 14 Jun 2005 16:48:01 -0700
Message-ID: <018d01c5713b$8069be70$c302000a@internal.toppro.net>
To: "Ben Curtis" <bcurtis@bivia.com>, <www-style@w3.org>


----- Original Message ----- 
From: "Ben Curtis" <bcurtis@bivia.com>
To: <www-style@w3.org>
Sent: Tuesday, June 14, 2005 3:35 PM
Subject: 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?

Yes, the idea is simple:

total = min(100%%, total-sum-of-%%-along-axis)

Using this total particular length value calculated as
x = free-space * X%% / total;

As I mentioned before this gives us known flexibility:
%% can be used as pure free space percents (if sum is <= 100)
or as weights.

Your example will behave exactly as current implementation in tables:
<table><tr><td width="75%">first</td>
                   <td width="75%">second</td></tr></table>

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

In fact any UA now has %% implemented internally.
At least table layout computation is using exactly the same or
very close principles. We don't need to invent anything major here
and to introduce new principles. Web designers already know
how to deal with them (in tables).

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

Exactly!  %% allows to keep layout in-flow as
much as possible. I think that everybody agree with such
motivation.

In my opinion calc is useful when it allows to refer to computed
values of other elements to calculate some values of given element.
I tried couple of times to implement it.
Stopped when I got first cyclic reference. I've got an oscillating layout :)
And this problem is huge and has no deterministic solution.


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

Again, in my opinion,  calc makes sense when you will be able to do 
following

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

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

Otherwise you are getting redundant declarations. As you've mentioned
this is just not working for design in teams, etc.

--------------------------------------------------

%% example from my previous message:

<div>top</div>
<div style="margin-top:100%%">bottom</div>

will position 'top' at top of the conatiner and
'bottom' at bottom.

Clear, simple, natural and does not break the idea of HTML/CSS.
Isn't it?

Andrew Fedoniouk.
http://terrainformatica.com



>
> -- 
>
> Ben Curtis : webwright
> bivia : a personal web studio
> http://www.bivia.com
> v: (818) 507-6613
>
>
>
>
> 
Received on Tuesday, 14 June 2005 23:48:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:37 GMT