W3C home > Mailing lists > Public > www-style@w3.org > March 2001

RE: inter-area text-flow

From: Mjumbe Ukweli <mjumbewu@hotmail.com>
Date: Sun, 18 Mar 2001 22:40:00 -0500
To: www-style@w3.org
Message-ID: <F129qNI4lQ5tX60LUDA0000551d@hotmail.com>
i first wondered why there was not an attribute that allows two elements to 
be 'linked' giving one a kind of overflow drain to the next?

#element1 {
  position: absolute;  left: 100px;  top: 100px;
  width: 200px;  height: 200px;

  overflow-drain (or some otherwise named property): #element2;
#element2 {
  position: absolute;  left: 300px; top: 300px;
  width: 200px;  height: 200px;

however, i realise that that would be contrary to the principles of 
separation of style from content.  if extra elements were placed in the 
documet strictly for the purpose of catching overflow then they would be 
considered elements for style.  whether or not that is a basis for rejection 
from CSS i don't know.

but what about this: would it be so bad if the designer could specify 
multiple positions for an element?  for example:

#element1 {
  position: absolute;
  left: 100px, 300px;
  top: 100px, 300px;
  width: 100px;
  height: 200px, 300px;

in this scenario 'element1' would be two boxes and have two positions, 
(100,100) and (300,300).  it would be 100 pixels wide at both of these 
positions, and 200px high at the first while 300px high at the second.  the 
overflow from the first box could continue onto the second.  it's basically 
treating the attributes as arrays instead of scalars.  left[0] = 100px and 
left[1] = 300px.  both width[0] and width[1] would equal 100px, since there 
is only one value specified.  and i don't see any conflict with the 
style-content separation.

well, that's what i came up with.  i just ask that you don't hurt me too bad 
(i'm only 17).  and thanks for listening.

                                                  &#8226; mjumbe &#8226;

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Received on Sunday, 18 March 2001 22:40:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:57 UTC