Re: Relative positioning

Greetings,

Sjoerd Visscher wrote:
> 
> > > I mean, with absolute positioning, elements are positioned
> > > completely independently as if they have no knowledge of each other,
> > > and with relative positioning, elements are positioned only relative
> > > to the normal flow. This effectively means that the two types of
> > > positioning can't really be used together very well, and what seems
> > > to be missing is a mechanism for positioning one element relative to
> > > an absolutely positioned (and perhaps named) element, thereby
> > > avoiding potential overlap problems.
> >
> > Can you give us a more concrete example?
> 
> That's not too hard. I've had this problem many times,
> usually when I want to create some kind of popup.
> 
> A conrete example is the menu at microsoft.com. (with IE4+)
> The menubar is part of the flow.
> But the menupopups are absolute positioned.
> The topleft corners of the menupopups must be equal to the bottom-left
> corner of the menubar items.
> 
> The problem is that this is impossible to code. (using DOM)
> The DOM does not want to supply interfaces for run-time properties like the
> absolute positions of relative positioned elements.
> 

But what I'm talking about is NOT getting the position of relatively
positioned elements. What I'm talking about is getting the position
of absolutely positioned elements, so that one absolute element can
be placed relative to another absolutely positioned element. I wouldn't
think THAT should be impossible. I mean, the coordinates of absolutely
positioned elements must be available if they are to be positioned
properly in the first place. All I'm suggesting is another sort of
"inheritance" or control mechanism.

> The maximum flexibility would be given, if CSS would support the following:
> - which element should the AP coordinates be relative to.
> - at what position of this element (similar to background-position)
>   for a menubar item this woud be 0% 100%
> - at what position of the AP element (also similar to background-position)
>   for a menupopup this would be 0% 0% (the default)
> 
> I don't think I made myself clear here.
> Does someone know some nice words for the various positions?
> 
> Reference element
> +------------------------------+
> |                  :           |
> |     AP element   :           |
> |     +------------:-----------------+
> |     |            :           |     |
> |..................+.................|
> |     |            : Reference |     |
> |     |            : point     |     |
> |     |            :           |     |
> +-----|------------:-----------+     |
>       |            :                 |
>       +------------------------------+
> 
> Setting both positions to 50% 50% would put the AP element in the center of
> the reference element.
> 
> I agree with Rick Johnson that such functionality is almost required if you
> need to use abs. pos. in a document which consist of mainly static
> positioned elements. (ie. almost all documents on the WWW)
> 

Would this not be even more useful for programs that generate pages
dynamically or from stored data? Essentially what I'm suggesting amounts 
to mapping out an absolute coordinate system in browser space with the 
capability for referencing elements to the origin, to some other x,y,z 
coordinates, or to each other. I would bet that every programmer on this
list has programmed some construct like that at some point in their 
career, so how hard could it be to implement this?

>> The change here is that I added one paragraph of text to the MAIN div,
>> but made no change to the position of the FOOTER div. The result is
>> that they now overlap egregiously.
>> 

>This problem is relatively simple fixed:
>
>You place the main and footer inside another div.
>Then you make the new div absolutely positioned.
>The main and footer div will stack above eachother like the normally do.>
>
>I've modified your example to show this.
>

Thank you Sjord. My later examples in the sequence also did something
similar, but my point wasn't to show that the problem absolutely couldn't
be solved, but that the solutions are somewhat inelegant and might be
better solved with my proposed mechanism. I mean, how many levels of
DIV can one nest? How many does one WANT to? I mean, isn't part of the
obscenity of tables the messiness of nesting them? And when I program,
I generally figure I've written sloppy code if I end up with something
that nests three levels, so why allow myself to be sloppier in HTML/CSS?

Additionally, my suggestion might minimize some of the problems with
things like OVERFLOW, CLIP, and such, (which currently don't function anyway)
and also make it easy to create "boxes" that are circles, ovals, etc.. (which 
I recall this forum discussed some time ago). Personally, I'd LOVE to be able 
to specify "boxes" that have alternate shapes, and as near as I can tell, no 
such mechanism yet exists in CSS? (I'll gladly stand corrected on this if 
someone can describe how CSS DOES handles this in the currently released
broswers.)

Rick Johnson
firespring@nfx.net

Received on Wednesday, 2 February 2000 05:51:07 UTC