Re: Box model: min-margin and max-margin, max-padding and min-padding

I've been reading Elliotte's pages for the last few days, and insofar 
as I can see what he's trying to do is

---------------------
| (1) Header        |
---------------------
| (2) Content | (3) |
|             |  S  |
|             |  i  |
|             |  d  |
|             |  e  |
|             |  b  |
|             |  a  |
|             |  r  |
---------------------

Right now:
1 is position: static
2 is position: static
3 is position: absolute

All 3 are divs, and so they're display: block

My understanding is:
1 is sitting in the normal page flow (position: static)
2 is in the normal flow too (position: static) - it goes below because 
both 1 & 2 are blocks
3 is also a block element, so it would normally be below 2, but as its 
absolutely positioned it is on the right.

Sidebar (3) should sit to the right of Content (2). Sidebar (3) should 
be as wide as it needs to be, with the Content (2) getting the rest of 
the available width. In other words, 2 & 3 are positioned "relative" to 
each other - there's some margin between them, but ultimately if (3) 
gets wider (2) should get narrower.

Insofar as I can tell, there's NO ideal way to do this in CSS. Sidebar 
(3) is a block level element and it naturally wants to go below Content 
(2). The obvious way to get it alongside is to make it 'position: 
absolute', but then its taken out of the flow and it ignores the size 
of the Content (2).

Group: is this something where 'display: run-in' would be useful 
(obviously, that's not actually implemented in browsers)

Is there a way of achieving this layout I haven't thought of?

On Sep 30, 2004, at 10:34 AM, Elliotte Harold wrote:

>
> Bjoern Hoehrmann wrote:
>
>
>> It seems you want to place an element relative to another element, why
>> would you use absolute positioning at all here?
>
> I need to place element C below element A and to the right of element 
> B.  i.e. header, sidebar, and content. The other constraint is that in 
> the HTML source element C (the sidebar) must come *after* the content 
> in accordance with web accessibility guidelines and compatibility with 
> older browsers. Therefore floats don't solve the problem because a 
> floated element only floats next to an element that follows it, not 
> one that precedes it.

AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside

         (see you later space cowboy ...)

Received on Friday, 1 October 2004 03:41:21 UTC