What am I not understanding about the definition of { position: absolute; }?

"The box's position (and possibly size) is specified with the 'left',
'right', 'top', and 'bottom' properties. These properties specify offsets
with respect to the box's containing block."

Please take a look at http://gavelcade.com/abspos.html and help me
understand why my nested, absolutely positioned divs are being positioned
with respect to the page rather than to their containing block, in IE6,
Mozilla, AND Opera. The result is the same whether or not the headers are
wrapped in their own div.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

Harlan Messinger wrote:
[color=blue]
> What am I not understanding about the definition of { position: absolute; }?
>
> "The box's position (and possibly size) is specified with the 'left',
> 'right', 'top', and 'bottom' properties. These properties specify offsets
> with respect to the box's containing block."
>
> Please take a look at http://gavelcade.com/abspos.html and help me
> understand why my nested, absolutely positioned divs are being positioned
> with respect to the page rather than to their containing block, in IE6,
> Mozilla, AND Opera. The result is the same whether or not the headers are
> wrapped in their own div.[/color]

Read section 9.8.4 Absolute positioning, it clearly states:
The containing block for a positioned box is established by the
nearest positioned ancestor (or, if none exists, the initial containing
block, as in our example).
--

Martin Honnen
http://JavaScript.FAQTs.com/

"Martin Honnen" <mahotrash@yahoo.de> wrote in message
news:401a9713$0$17560$9b4e6d93@newsread4.arcor-online.net...[color=blue]
>
>
> Harlan Messinger wrote:
>[color=green]
> > What am I not understanding about the definition of { position:[/color][/color]
absolute; }?[color=blue][color=green]
> >
> > "The box's position (and possibly size) is specified with the 'left',
> > 'right', 'top', and 'bottom' properties. These properties specify[/color][/color]
offsets[color=blue][color=green]
> > with respect to the box's containing block."
> >
> > Please take a look at http://gavelcade.com/abspos.html and help me
> > understand why my nested, absolutely positioned divs are being[/color][/color]
positioned[color=blue][color=green]
> > with respect to the page rather than to their containing block, in IE6,
> > Mozilla, AND Opera. The result is the same whether or not the headers[/color][/color]
are[color=blue][color=green]
> > wrapped in their own div.[/color]
>
> Read section 9.8.4 Absolute positioning, it clearly states:
> The containing block for a positioned box is established by the
> nearest positioned ancestor (or, if none exists, the initial containing
> block, as in our example).[/color]

I see. The problem is that it didn't occur to me to look for a definition
for something that looked like perfectly clear English as it was. :-)
"Containing block" looks pretty unambiguous to me!

Now that I know this, it strikes me as *extremely* unfortunate. I thought it
enabled one to build reusable, repeatable sections of a page, an specify
identical layouts (at the pixel level) for all of them. Each would be
defined by a statically positioned parent block occurring in the normal page
flow. Each parent block would be filled with child blocks positioned
absolutely *with respect to their parent*, with the positioning parameters
based on their classes. Each child block would be of the *same* class as the
corresponding children of the other parents.

So this isn't possible, or is there another way to do it?

Good evening Harlan,


It was foretold that on 30-1-2004 @ 13:29:14 GMT-0500 (which was
19:29:14 where I live) Harlan Messinger would mumble:

<snipped a bit>

HM> Each parent block would be filled with child blocks positioned
HM> absolutely *with respect to their parent*,
HM> So this isn't possible, or is there another way to do it?

If i understand you correctly, you want the parent element to be the
containing block of the AP element?

You might try setting "position: relative" with no offsets to the
element you want to use as an CB, but don't shoot me if it doesn't
work: just guessing here.

--
Best regards,
lukie

--------------------------------------------
Powered by The Bat! version 1.63 Beta/7 with Windows 2000 (build
2195), version 5.0 Service Pack 4 and using the best browser: Opera.

"In California, 50 women protested the impending war with Iraq by
lying on the ground naked and spelling out the word 'peace.' Right
idea, wrong president." - Jay Leno
--------------------------------------------


__________________________________________________ ______________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)

"Harlan Messinger" <h.messinger@comcast.net> wrote:[color=blue]
>"Martin Honnen" <mahotrash@yahoo.de> wrote in message
>news:401a9713$0$17560$9b4e6d93@newsread4.arcor-online.net...[/color]
[color=blue][color=green]
>> Read section 9.8.4 Absolute positioning, it clearly states:
>> The containing block for a positioned box is established by the
>> nearest positioned ancestor (or, if none exists, the initial containing
>> block, as in our example).[/color]
>
>I see. The problem is that it didn't occur to me to look for a definition
>for something that looked like perfectly clear English as it was. :-)
>"Containing block" looks pretty unambiguous to me!
>
>Now that I know this, it strikes me as *extremely* unfortunate. I thought it
>enabled one to build reusable, repeatable sections of a page, an specify
>identical layouts (at the pixel level) for all of them. Each would be
>defined by a statically positioned parent block occurring in the normal page
>flow. Each parent block would be filled with child blocks positioned
>absolutely *with respect to their parent*, with the positioning parameters
>based on their classes. Each child block would be of the *same* class as the
>corresponding children of the other parents.
>
>So this isn't possible, or is there another way to do it?[/color]

Just add position: relative; to the styles for the parent element. A
relatively positioned element with no top, left, right or bottom
values will occupy exactly the same position as a statically
positioned element. All absolutely positioned children will now be
positioned relative to that parent rather than to the page.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

"Steve Pugh" <steve@pugh.net> wrote in message
news:ceal10pbp4fcfjtpanmkkq47u616liqjvq@4ax.com...[color=blue]
> "Harlan Messinger" <h.messinger@comcast.net> wrote:[color=green]
> >"Martin Honnen" <mahotrash@yahoo.de> wrote in message
> >news:401a9713$0$17560$9b4e6d93@newsread4.arcor-online.net...[/color]
>[color=green][color=darkred]
> >> Read section 9.8.4 Absolute positioning, it clearly states:
> >> The containing block for a positioned box is established by the
> >> nearest positioned ancestor (or, if none exists, the initial containing
> >> block, as in our example).[/color]
> >
> >I see. The problem is that it didn't occur to me to look for a definition
> >for something that looked like perfectly clear English as it was. :-)
> >"Containing block" looks pretty unambiguous to me!
> >
> >Now that I know this, it strikes me as *extremely* unfortunate. I thought[/color][/color]
it[color=blue][color=green]
> >enabled one to build reusable, repeatable sections of a page, an specify
> >identical layouts (at the pixel level) for all of them. Each would be
> >defined by a statically positioned parent block occurring in the normal[/color][/color]
page[color=blue][color=green]
> >flow. Each parent block would be filled with child blocks positioned
> >absolutely *with respect to their parent*, with the positioning[/color][/color]
parameters[color=blue][color=green]
> >based on their classes. Each child block would be of the *same* class as[/color][/color]
the[color=blue][color=green]
> >corresponding children of the other parents.
> >
> >So this isn't possible, or is there another way to do it?[/color]
>
> Just add position: relative; to the styles for the parent element. A
> relatively positioned element with no top, left, right or bottom
> values will occupy exactly the same position as a statically
> positioned element. All absolutely positioned children will now be
> positioned relative to that parent rather than to the page.[/color]

Aha. It works. But relative positioning isn't absolute positioning, so I'm
left puzzled by how, given the definition of "containing block", this turns
the parent div into a containing block.

"Harlan Messinger" <h.messinger@comcast.net> wrote:[color=blue]
>"Steve Pugh" <steve@pugh.net> wrote in message
>news:ceal10pbp4fcfjtpanmkkq47u616liqjvq@4ax.com.. .[/color]
[color=blue][color=green]
>> Just add position: relative; to the styles for the parent element.[/color]
>
>Aha. It works. But relative positioning isn't absolute positioning, so I'm
>left puzzled by how, given the definition of "containing block", this turns
>the parent div into a containing block.[/color]

This definition:
"The containing block for a positioned box is established by the
nearest positioned ancestor (or, if none exists, the initial
containing block, as in our example)."

It says the nearest positioned block (which means the nearest block
with position set to anything other than static) not the nearest
absolutely positioned block.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

"Steve Pugh" <steve@pugh.net> wrote in message
news:95il1016uh03niki6cnq07adt44mrh9fkt@4ax.com...[color=blue]
> "Harlan Messinger" <h.messinger@comcast.net> wrote:[color=green]
> >"Steve Pugh" <steve@pugh.net> wrote in message
> >news:ceal10pbp4fcfjtpanmkkq47u616liqjvq@4ax.com.. .[/color]
>[color=green][color=darkred]
> >> Just add position: relative; to the styles for the parent element.[/color]
> >
> >Aha. It works. But relative positioning isn't absolute positioning, so[/color][/color]
I'm[color=blue][color=green]
> >left puzzled by how, given the definition of "containing block", this[/color][/color]
turns[color=blue][color=green]
> >the parent div into a containing block.[/color]
>
> This definition:
> "The containing block for a positioned box is established by the
> nearest positioned ancestor (or, if none exists, the initial
> containing block, as in our example)."
>
> It says the nearest positioned block (which means the nearest block
> with position set to anything other than static) not the nearest
> absolutely positioned block.[/color]

Oh, OK, I see. That's the mistake I was making. Thanks.

Harlan Messinger wrote:[color=blue]
>
> I thought it
> enabled one to build reusable, repeatable sections of a page, an specify
> identical layouts (at the pixel level) for all of them.[/color]

FYI, you cannot get pixel-precision unless perhaps you are dealing only
with graphics (and your visitors always enable image loading). It
cannot work reliably with text elements, since you have no control over
the visitor's fonts or text size.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

"Harlan Messinger" <h.messinger@comcast.net> wrote:
[color=blue]
>
>"Steve Pugh" <steve@pugh.net> wrote in message
>news:95il1016uh03niki6cnq07adt44mrh9fkt@4ax.com.. .[color=green]
>> "Harlan Messinger" <h.messinger@comcast.net> wrote:[color=darkred]
>> >"Steve Pugh" <steve@pugh.net> wrote in message
>> >news:ceal10pbp4fcfjtpanmkkq47u616liqjvq@4ax.com.. .[/color]
>>[color=darkred]
>> >> Just add position: relative; to the styles for the parent element.
>> >
>> >Aha. It works. But relative positioning isn't absolute positioning, so[/color][/color]
>I'm[color=green][color=darkred]
>> >left puzzled by how, given the definition of "containing block", this[/color][/color]
>turns[color=green][color=darkred]
>> >the parent div into a containing block.[/color]
>>
>> This definition:
>> "The containing block for a positioned box is established by the
>> nearest positioned ancestor (or, if none exists, the initial
>> containing block, as in our example)."
>>
>> It says the nearest positioned block (which means the nearest block
>> with position set to anything other than static) not the nearest
>> absolutely positioned block.[/color]
>
>Oh, OK, I see. That's the mistake I was making. Thanks.[/color]

Well, then, any ideas why they didn't just define the positioning of
absolutely positioned items to be relative to their parent,
*regardless* of the positioning of the parent? I don't see the benefit
of positioning a block relative to anything *but* its parent. If I
wanted it positioned relative to another block, wouldn't I just have
put it into that other block?

Just now I thought of one possible reason, but I wonder if that's the
W3C's reason. Maybe it's supposed to allow text to be positioned out
of its logical sequence on the visual page, in cases where other
visual cues establish the reading order for visual users (such as a
case where banner-sized text is naturally read first even if it's not
positioned at the upper left), while leaving the text flow in its
natural order in the page's source.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

kchayka <kcha-un-yka@sihope.com> wrote:
[color=blue]
>Harlan Messinger wrote:[color=green]
>>
>> I thought it
>> enabled one to build reusable, repeatable sections of a page, an specify
>> identical layouts (at the pixel level) for all of them.[/color]
>
>FYI, you cannot get pixel-precision unless perhaps you are dealing only
>with graphics (and your visitors always enable image loading).[/color]

True, with text you would have no control over where lines wrap or
even on the heights of the containing blocks, but you'd have control
over their left and right positions and their widths. I shouldn't have
said "pixel-precision" without qualifying it.
[color=blue]
> It
>cannot work reliably with text elements, since you have no control over
>the visitor's fonts or text size.[/color]


--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

Harlan Messinger wrote:[color=blue]
>
> any ideas why they didn't just define the positioning of absolutely
> positioned items to be relative to their parent, *regardless* of
> the positioning of the parent? I don't see the benefit of
> positioning a block relative to anything *but* its parent. If I
> wanted it positioned relative to another block, wouldn't I just
> have put it into that other block?
>
> Maybe it's supposed to allow text to be positioned out of its
> logical sequence on the visual page,[/color]

I don't know for sure, but that seems to make the most sense. As one
example, it allows an author to take a nested div and position it with
respect to the browser window, while leaving the other content of the
parent div to flow normally.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Harlan Messinger wrote:
[color=blue]
> "Martin Honnen" <mahotrash@yahoo.de> wrote in message
> news:401a9713$0$17560$9b4e6d93@newsread4.arcor-online.net...
>[color=green]
>>
>>Harlan Messinger wrote:
>>
>>[color=darkred]
>>>What am I not understanding about the definition of { position:[/color][/color]
>
> absolute; }?
>[color=green][color=darkred]
>>>"The box's position (and possibly size) is specified with the 'left',
>>>'right', 'top', and 'bottom' properties. These properties specify[/color][/color]
>
> offsets
>[color=green][color=darkred]
>>>with respect to the box's containing block."
>>>
>>>Please take a look at http://gavelcade.com/abspos.html and help me
>>>understand why my nested, absolutely positioned divs are being[/color][/color]
>
> positioned
>[color=green][color=darkred]
>>>with respect to the page rather than to their containing block, in IE6,
>>>Mozilla, AND Opera. The result is the same whether or not the headers[/color][/color]
>
> are
>[color=green][color=darkred]
>>>wrapped in their own div.[/color]
>>
>>Read section 9.8.4 Absolute positioning, it clearly states:
>> The containing block for a positioned box is established by the
>>nearest positioned ancestor (or, if none exists, the initial containing
>>block, as in our example).[/color]
>
>
> I see. The problem is that it didn't occur to me to look for a definition
> for something that looked like perfectly clear English as it was. :-)
> "Containing block" looks pretty unambiguous to me!
>
> Now that I know this, it strikes me as *extremely* unfortunate. I thought it
> enabled one to build reusable, repeatable sections of a page, an specify
> identical layouts (at the pixel level) for all of them. Each would be
> defined by a statically positioned parent block occurring in the normal page
> flow. Each parent block would be filled with child blocks positioned
> absolutely *with respect to their parent*, with the positioning parameters
> based on their classes. Each child block would be of the *same* class as the
> corresponding children of the other parents.
>
> So this isn't possible, or is there another way to do it?
>[/color]


Set the parent style to:
style="position:relative; ..." and do not set top or left or right or
bottom values to that parent element (otherwise set these to auto).
For any easy testing of this:

Interactive demo on CSS positionning
http://www10.brinkster.com/doctorunc...sitioning.html

where your parent could be either the blue or yellow div while your
child is the red one.

DU

kchayka wrote:
[color=blue]
> Harlan Messinger wrote:
>[color=green]
>>I thought it
>>enabled one to build reusable, repeatable sections of a page, an specify
>>identical layouts (at the pixel level) for all of them.[/color]
>
>
> FYI, you cannot get pixel-precision unless perhaps you are dealing only
> with graphics (and your visitors always enable image loading). It
> cannot work reliably with text elements, since you have no control over
> the visitor's fonts or text size.
>[/color]

I disagree... unless the page is excessively complex and/or targeted
browsers CSS support/compliance is poor/buggy. Text elements' font size,
font family, etc... are pretty much irrelevant. If such text is within
an element, block-level or inline, then such element's will be
positionable accurately (via their top, left, bottom and/or right offsets).

DU

Harlan Messinger <hmessinger.removethis@comcast.net> wrote in message news:<hggn109gvqq1ch53hb3dq8jijjp6ag06g8@4ax.com>. ..[color=blue]
> kchayka <kcha-un-yka@sihope.com> wrote:
>[color=green]
> >Harlan Messinger wrote:[color=darkred]
> >>
> >> I thought it
> >> enabled one to build reusable, repeatable sections of a page, an specify
> >> identical layouts (at the pixel level) for all of them.[/color]
> >
> >FYI, you cannot get pixel-precision unless perhaps you are dealing only
> >with graphics (and your visitors always enable image loading).[/color]
>
> True, with text you would have no control over where lines wrap or
> even on the heights of the containing blocks, but you'd have control
> over their left and right positions and their widths. I shouldn't have
> said "pixel-precision" without qualifying it.
>[color=green]
> > It
> >cannot work reliably with text elements, since you have no control over
> >the visitor's fonts or text size.[/color][/color]

Don't know if it's relevant but I use the margin-top, margin-left
properties to position elements - the containing box requires a
vertical-align:top and text-align:left bias. Don't use the other
margin properties though - they're unreliable.