423,311 Members | 1,224 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,311 IT Pros & Developers. It's quick & easy.

Reason behind containing block rule

P: n/a
If you wrap one division around another like this:

<div id="wrapper">
<div id="child">...</div>
</div>

....the wrapper division will be considered the containing block of the child
division in all cases except where
1. the positioning of the wrapper is static and
2. the positioning of the child is absolute.

OK. So why? Why is that one case an exception? Surely the CSS standards
committee had a reason behind this. Surely they weren't just being
capricious. Were they drunk?

Sep 5 '06 #1
Share this Question
Share on Google+
26 Replies


P: n/a
"Bill Norton" <bn*****@austin.rr.comwrote:
>If you wrap one division around another like this:

<div id="wrapper">
<div id="child">...</div>
</div>

...the wrapper division will be considered the containing block of the child
division in all cases except where
1. the positioning of the wrapper is static and
2. the positioning of the child is absolute.

OK. So why? Why is that one case an exception? Surely the CSS standards
committee had a reason behind this. Surely they weren't just being
capricious. Were they drunk?
I'm not sure what you are asking.

In the absolute positioning model an absolutely positioned element is
positioned with respect to the nearest ancestor whose position property
has been set to anything other than the (default) value of static.

Absolutely positioned elements are taken out of the flow completely, it
would make no sense to always position them in respect to their parent
element. As defined we can choose which ancestor element acts as the
containing block which results in a usable scheme.

Does that answer your question?

--
Spartanicus
Sep 5 '06 #2

P: n/a

"Spartanicus" <in*****@invalid.invalidwrote in message
news:c1********************************@4ax.com...
In the absolute positioning model an absolutely positioned element is
positioned with respect to the nearest ancestor whose position property
has been set to anything other than the (default) value of static.
Right. That's how it's defined. The question really had to do with *why* it
was defined that way.
Absolutely positioned elements are taken out of the flow completely, it
would make no sense to always position them in respect to their parent
element. As defined we can choose which ancestor element acts as the
containing block which results in a usable scheme.
OK. But I'm having a hard time imagining a case where I would want to
position an element outside of its parent. And anyway if the idea is to give
me a choice as to which block I want to position something, then why not let
me be completely specific about it with, say, a container-block property
like this:

#divX {position: absolute; left: 0px; top: 0px; container-block:
divWhatever}

Sep 5 '06 #3

P: n/a
"Bill Norton" <bn*****@austin.rr.comwrote:
>Absolutely positioned elements are taken out of the flow completely, it
would make no sense to always position them in respect to their parent
element. As defined we can choose which ancestor element acts as the
containing block which results in a usable scheme.

OK. But I'm having a hard time imagining a case where I would want to
position an element outside of its parent.
Use what you need, leave the bits that you don't. I see no justification
for criticizing CSS for offering more options than you personally need.

--
Spartanicus
Sep 5 '06 #4

P: n/a
"Spartanicus" wrote
Use what you need, leave the bits that you don't. I see no justification
for criticizing CSS for offering more options than you personally need.
In application development we call this "feature bloat" and it's a thing to
be avoided. One should never add functionality just because you can. You
need to understand the users needs and build around that.

I wonder how many man hours have been wasted around the world by web
developers who have run into this "feature" and tried to figure out what was
going on.

I wonder what the ratio is of the number of times someone has actually taken
advantage of this "feature" vs. the number of times someone has had to work
around it by giving a parent block a token "position: relative" with no
offsets.

Sep 5 '06 #5

P: n/a
"Bill Norton" <bn*****@austin.rr.comwrote:
>Use what you need, leave the bits that you don't. I see no justification
for criticizing CSS for offering more options than you personally need.

In application development we call this "feature bloat" and it's a thing to
be avoided.
Again: just because you don't have a use for something doesn't mean that
there is no use for it.
>I wonder what the ratio is of the number of times someone has actually taken
advantage of this "feature" vs. the number of times someone has had to work
around it by giving a parent block a token "position: relative" with no
offsets.
Absolute positioning as a whole is not understood well by many. I've
been a regular in this group since about 1998, during that time this
particular aspect of it hasn't featured as being a problem of any
significance.

--
Spartanicus
Sep 5 '06 #6

P: n/a

"Spartanicus" wrote
Absolute positioning as a whole is not understood well by many. I've
been a regular in this group since about 1998, during that time this
particular aspect of it hasn't featured as being a problem of any
significance.
Indeed this may not be one of CSS's biggest problems - there are, after all,
so many to choose from :-) Still a quick Googel of this group on
'"containing block" absolute' came up with 95 hits. Of course not all were
relevant to the issue at hand but many were. Here are a couple of other
folk's comments on this "rule".

From Harlan Messinger (after having the problem explained to him)
"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 (rule), it strikes me as *extremely* unfortunate. "

From Gert Brinkmann
"Thank you very much for your answer. It's unbelievable, but it is true.
This
is the way, firefox behaves (I did not check other browsers). Hmm, does
this behaviour make sense? "

At this point - given what I understand about it - I have to see it as
another unfortunate decision on the part of W3C.
Sep 6 '06 #7

P: n/a
Bill Norton wrote:
If you wrap one division around another like this:

<div id="wrapper">
<div id="child">...</div>
</div>

...the wrapper division will be considered the containing block of the child
division in all cases except where
1. the positioning of the wrapper is static and
2. the positioning of the child is absolute.

OK. So why? Why is that one case an exception? Surely the CSS standards
committee had a reason behind this. Surely they weren't just being
capricious. Were they drunk?
Consider the following reasoning of the "Containing Block" (which
determines the relative positioning) in the following two instances:

A Relative div takes positioning which is offset from the position it
would have taken in Static. Consider that the Abs div's (0,0) if inside
a Rel div without Positioning Properties is the top/left of the Rel div
(not offset and therefore the same as if Static).

Static is the only one which does not take positioning properties such
as top, left, right, bottom whether Static Block Model or Static Inline
Model and is always within the normal flow of the document. If Static
were not an exception then it would not only duplicate the Rel div
without Positioning, but also as far as the Abs' positioning is
concerned. They instead make the positioning relative to the "Viewport"
for the Abs div.

Hopefully I have been able to convey my understanding on this and how it
relates to your question.

--
Gus
Sep 6 '06 #8

P: n/a

Bill Norton wrote:
In application development we call this "feature bloat" and it's a thing to
be avoided.
CSS isn't an application, it's a standard protocol. Different ground
rules.

Sep 6 '06 #9

P: n/a
"Gus Richter" wrote
If Static were not an exception then it would not only duplicate the Rel
div without Positioning, but also as far as the Abs' positioning is
concerned. They instead make the positioning relative to the "Viewport"
for the Abs div.
Thanks, Gus. If I understand you correctly the reason behind the
"Static/Absolute exception" is because the W3C didn't want to duplicate the
functionality of a "Relative with no Positioning/Absolute" nesting.

Well, if that's the case, then I have to tell you - that seems so, I dunno,
so arbitrary, so capricious. Heck, maybe they were drunk.

It's not like there's not any other duplicate functionality in CSS. It's
everywhere, and so what? That's not necessarily a bad thing.

Now, as I have been thinking about it, I can certainly see the benefit of
being able to place something outside of its parent block, and if that's
what they were trying to do then fine, but what a weird way of doing it. Why
not just allow us to explicitly state which containing block we want to
place something in with something like the container-block property I
mentioned in an earlier post?

#divX {
position: absolute;
left: 0px;
top: 0px;
container-block: divWhatever}

Sep 6 '06 #10

P: n/a
Spartanicus wrote:
"Bill Norton" <bn*****@austin.rr.comwrote:
>>Absolutely positioned elements are taken out of the flow completely, it
would make no sense to always position them in respect to their parent
element. As defined we can choose which ancestor element acts as the
containing block which results in a usable scheme.
OK. But I'm having a hard time imagining a case where I would want to
position an element outside of its parent.

Use what you need, leave the bits that you don't. I see no justification
for criticizing CSS for offering more options than you personally need.
Holy cow. What if understanding the reason for this revealed to Bill
some techniques using CSS he wasn't aware of before?

I've been as curious as Bill about the reason for this. It's a valid
question. Do you know the answer or don't you? What's your motivation
for trying to stifle someone else's curiosity about why something was
done a particular way?
Sep 6 '06 #11

P: n/a
Gus Richter wrote:
Bill Norton wrote:
>If you wrap one division around another like this:

<div id="wrapper">
<div id="child">...</div>
</div>

...the wrapper division will be considered the containing block of the
child division in all cases except where
1. the positioning of the wrapper is static and
2. the positioning of the child is absolute.

OK. So why? Why is that one case an exception? Surely the CSS
standards committee had a reason behind this. Surely they weren't just
being capricious. Were they drunk?

Consider the following reasoning of the "Containing Block" (which
determines the relative positioning) in the following two instances:

A Relative div takes positioning which is offset from the position it
would have taken in Static. Consider that the Abs div's (0,0) if inside
a Rel div without Positioning Properties is the top/left of the Rel div
(not offset and therefore the same as if Static).

Static is the only one which does not take positioning properties such
as top, left, right, bottom whether Static Block Model or Static Inline
Model and is always within the normal flow of the document. If Static
were not an exception then it would not only duplicate the Rel div
without Positioning, but also as far as the Abs' positioning is
concerned. They instead make the positioning relative to the "Viewport"
for the Abs div.

Hopefully I have been able to convey my understanding on this and how it
relates to your question.
For me it only opens up the question of why both static and relative
positioning exist, if one is just the other with no offsets specified.

Besides that, instead of having one pair of constructs with the same
behavior, now they have another set of constructs with the same
behavior: having an absolutely positioned element inside a statically
positioned element is the same has having the absolutely positioned
element directly inside the body. If I intend to position an element
absolutely with respect to the viewport, why would I be including it in
*any* DIV?
Sep 6 '06 #12

P: n/a
Harlan Messinger <hm*******************@comcast.netwrote:
>Use what you need, leave the bits that you don't. I see no justification
for criticizing CSS for offering more options than you personally need.

Holy cow. What if understanding the reason for this revealed to Bill
some techniques using CSS he wasn't aware of before?

I've been as curious as Bill about the reason for this. It's a valid
question. Do you know the answer or don't you? What's your motivation
for trying to stifle someone else's curiosity about why something was
done a particular way?
I've provided an answer to his question. In addition I criticise his
criticism of w3c for providing features which he doesn't need, and that
doing so only serves to confuse authors.

I don't use CSS as a bag of tricks that I all need to know. I use CSS to
solve real world problems that I have. That means that I cannot provide
you with a comprehensive list of reasons why shifting the containing
block to another element than the parent element could be useful.

One example that I can remember where I used it was to position a logo
image in a sidebar whereas its correct place in the markup was in the
"content" section: http://www.pan-europe.utvinternet.ie/index.htm
(I don't recommend looking at the code used on that site, it is likely
to confuse the casual observer, understanding the coding requires an
extensive explanation as to why things were done the way they were)

There may be many more uses and better examples than the example above,
including other examples where I've used it that I forgot about.

For anyone who wants to learn more about how CSS developed I'd suggest
you check out the www-style mailing list archive at w3.org, or read
Hakon Wium Lie's PHD thesis http://people.opera.com/howcome/2006/phd/
which IIRC contains an introduction that explains some of the CSS
history.

--
Spartanicus
Sep 6 '06 #13

P: n/a
"Spartanicus" wrote
I've provided an answer to his question. In addition I criticise his
criticism of w3c for providing features which he doesn't need, and that
doing so only serves to confuse authors.
Well, then. I criticise your criticism of my criticism.

Actually I don't have that much of a problem with W3C "providing features
which (I don't) need." What I have a problem with is the arbitrary and
non-intuitive way they went about it.

If they want to let me place elements in any old containing block then
great. Even if I never used the feature, at least it makes sense to have
that ability. But don't implement it by shoe-horning it into some exception
to what should be a simple and straightforward rule. And don't implement it
in some half-baked manner by limiting it to the nearest ancestor containing
block that is positioned.
Sep 6 '06 #14

P: n/a
"Bill Norton" <bn*****@austin.rr.comwrote:
>I've provided an answer to his question. In addition I criticise his
criticism of w3c for providing features which he doesn't need, and that
doing so only serves to confuse authors.

Well, then. I criticise your criticism of my criticism.

Actually I don't have that much of a problem with W3C "providing features
which (I don't) need." What I have a problem with is the arbitrary and
non-intuitive way they went about it.

If they want to let me place elements in any old containing block then
great. Even if I never used the feature, at least it makes sense to have
that ability. But don't implement it by shoe-horning it into some exception
to what should be a simple and straightforward rule. And don't implement it
in some half-baked manner by limiting it to the nearest ancestor containing
block that is positioned.
That's quite different from the objection you started out with. I'm on
record as a long time critic of parts of the CSS spec, this includes
positioning (as a whole), collapsing margins, float rules etc.

I seem to remember reading somewhere (here probably) that abs
positioning as currently incorporated in CSS2 is a mix of techniques
developed by MS and Netscape, and that it wasn't properly scrutinized
for its merits and flaws by the wider CSS community in the way that is
currently the norm.

--
Spartanicus
Sep 6 '06 #15

P: n/a
Spartanicus wrote:
Harlan Messinger <hm*******************@comcast.netwrote:
>>Use what you need, leave the bits that you don't. I see no justification
for criticizing CSS for offering more options than you personally need.
Holy cow. What if understanding the reason for this revealed to Bill
some techniques using CSS he wasn't aware of before?

I've been as curious as Bill about the reason for this. It's a valid
question. Do you know the answer or don't you? What's your motivation
for trying to stifle someone else's curiosity about why something was
done a particular way?

I've provided an answer to his question.
I only saw you re-explain to him the *what*, which is what led to his
question in the first place, not the *why*, which is what he asked.

[snip]
There may be many more uses and better examples than the example above,
including other examples where I've used it that I forgot about.

For anyone who wants to learn more about how CSS developed I'd suggest
you check out the www-style mailing list archive at w3.org, or read
Hakon Wium Lie's PHD thesis http://people.opera.com/howcome/2006/phd/
which IIRC contains an introduction that explains some of the CSS
history.
I knew a constructive response lay somewhere therein! Thanks.

Sep 6 '06 #16

P: n/a
Harlan Messinger wrote:
>
For me it only opens up the question of why both static and relative
positioning exist, if one is just the other with no offsets specified.
Well, with Static you cannot specify offsets, but with Rel you can. The
example given is in the instance where no offset is used for Rel, which
will be the same as Static only in that particular instance.
Besides that, instead of having one pair of constructs with the same
behavior, now they have another set of constructs with the same
behavior: having an absolutely positioned element inside a statically
positioned element is the same has having the absolutely positioned
element directly inside the body. If I intend to position an element
absolutely with respect to the viewport, why would I be including it in
*any* DIV?
I don't know the whyfor - I just read the specs. I also agree that (at
this time) I see no use for Abs inside Static. I have not tested out all
the different possibilities. I have only found use for Abs in Rel so far.

It may be to ensure that for Static, which mirrors the traditional HTML
positioning model with elements placed within a continuous flow that
represent the HTML page, they wanted to make sure that Abs will be "out
of the normal flow".

--
Gus
Sep 6 '06 #17

P: n/a
Bill Norton wrote:
>
Now, as I have been thinking about it, I can certainly see the benefit of
being able to place something outside of its parent block, and if that's
what they were trying to do then fine, but what a weird way of doing it. Why
not just allow us to explicitly state which containing block we want to
place something in with something like the container-block property I
mentioned in an earlier post?

#divX {
position: absolute;
left: 0px;
top: 0px;
container-block: divWhatever}
I prefer to have less than more properties possibilities. I like the
simplicity of nesting ("a box's containing block" means "the containing
block in which the box lives"). The instance of an Abs nested inside a
Static is ensured to be out of the normal flow by item 4. in:
<http://www.w3.org/TR/CSS21/visudet.html#containing-block-details>
Also read my response to Harlan.

--
Gus
Sep 6 '06 #18

P: n/a
Gus Richter wrote:
Harlan Messinger wrote:
>>
For me it only opens up the question of why both static and relative
positioning exist, if one is just the other with no offsets specified.

Well, with Static you cannot specify offsets, but with Rel you can.
I know, but that leaves unexplained the *utility* of having a display
mode that doesn't enable offsets in addition to one that allows offsets
but that just as well allows them to be omitted.

<silliness>
It makes sense if somehow one developer has control over the Display
property and another has control over offsets but only for those items
where the Display developer chooses to give him control by setting
display="relative". This would give the Display person enforcement over
offset policy. But assuming a single developer is involved, he isn't
enforcing anything by using "static". If he mischievously decides to
define offsets, he can just as easily change "static" to "relative" first!
</silliness>
Sep 6 '06 #19

P: n/a
"Gus Richter" wrote
I prefer to have less than more properties possibilities.
I don't see it as a question of more vs. fewer properties but rather as a
question of usability and intuitiveness. If it makes sense to add another
property to implement some functionality, then by all means add another
property. If it makes more sense to use an existing property somehow, then
by all means, use the existing property.

What they've done with the "Static/Absolute Exception" makes no sense at
all. What they have done is to take a completely legitimate positioning
option (an absolutely positioned element inside a static block) and to
arbitrarily define it as behaving in a completely non-intuitive way.
Sep 6 '06 #20

P: n/a
"Gus Richter" wrote
I don't know the whyfor - I just read the specs. I also agree that (at
this time) I see no use for Abs inside Static.
Hmmm... Let's explore this for a moment, if you don't mind. Is there
something inherently wrong with giving an element absolute positioning
inside a static block?

I can't see that there is.

Harlan makes a very good observation that static positioning is nothing more
than relative positioning without the offsets. Put another way relative
positioning is nothing more than static positioning *with* offsets. So if
it's legitimate to absolutely position something within a relative block,
then it should be just as legitimate to do the same thing inside a static
block.

Sep 6 '06 #21

P: n/a
Bill Norton wrote:
>
What they've done with the "Static/Absolute Exception" makes no sense at
all. What they have done is to take a completely legitimate positioning
option (an absolutely positioned element inside a static block) and to
arbitrarily define it as behaving in a completely non-intuitive way.
I referred you to my response to Harlan in which I said:
Static mirrors the traditional HTML positioning model with elements
placed within a continuous flow that represent the HTML page and they
(probably) wanted to make sure that Abs will be "out of the normal flow".

My thinking is that this was the starting point and moved on to other
possibilities from there. Makes sense to me.

--
Gus
Sep 7 '06 #22

P: n/a
Harlan Messinger wrote:
Gus Richter wrote:
>Harlan Messinger wrote:
>>>
For me it only opens up the question of why both static and relative
positioning exist, if one is just the other with no offsets specified.

Well, with Static you cannot specify offsets, but with Rel you can.

I know, but that leaves unexplained the *utility* of having a display
mode that doesn't enable offsets in addition to one that allows offsets
but that just as well allows them to be omitted.

<silliness>
It makes sense if somehow one developer has control over the Display
property and another has control over offsets but only for those items
where the Display developer chooses to give him control by setting
display="relative". This would give the Display person enforcement over
offset policy. But assuming a single developer is involved, he isn't
enforcing anything by using "static". If he mischievously decides to
define offsets, he can just as easily change "static" to "relative" first!
</silliness>
Although I have not as yet done so, nor do I know if anyone has already
done so, but I see the possibility of scripting to change the offsets
and indeed also the Positioning Models, etc. This may be what you're
driving at?

--
Gus
Sep 7 '06 #23

P: n/a
Bill Norton wrote:
"Gus Richter" wrote
>I don't know the whyfor - I just read the specs. I also agree that (at
this time) I see no use for Abs inside Static.

Hmmm... Let's explore this for a moment, if you don't mind. Is there
something inherently wrong with giving an element absolute positioning
inside a static block?

I can't see that there is.
I don't either. It is permissable, although I don't see the use of it.
Harlan makes a very good observation that static positioning is nothing more
than relative positioning without the offsets. Put another way relative
positioning is nothing more than static positioning *with* offsets.
Exactly so. If I have not said so yet, I say it now. Proof is that the
space (for Rel) is retained where it would have been, had it not been
moved (offset).
So if
it's legitimate to absolutely position something within a relative block,
then it should be just as legitimate to do the same thing inside a static
block.
Except for the fact that the specs specifically does not permit this.

--
Gus
Sep 7 '06 #24

P: n/a

"Gus Richter" wrote
Except for the fact that the specs specifically does not permit this.
Right, but now we're back to my original question. Why is it this way? Why,
why, why??? What were they thinking?

I've seen several theories offered, but none have traction for me.
Sep 7 '06 #25

P: n/a
Gus Richter wrote:
Harlan Messinger wrote:
>Gus Richter wrote:
>>Harlan Messinger wrote:

For me it only opens up the question of why both static and relative
positioning exist, if one is just the other with no offsets specified.

Well, with Static you cannot specify offsets, but with Rel you can.

I know, but that leaves unexplained the *utility* of having a display
mode that doesn't enable offsets in addition to one that allows
offsets but that just as well allows them to be omitted.

<silliness>
It makes sense if somehow one developer has control over the Display
property and another has control over offsets but only for those items
where the Display developer chooses to give him control by setting
display="relative". This would give the Display person enforcement
over offset policy. But assuming a single developer is involved, he
isn't enforcing anything by using "static". If he mischievously
decides to define offsets, he can just as easily change "static" to
"relative" first!
</silliness>

Although I have not as yet done so, nor do I know if anyone has already
done so, but I see the possibility of scripting to change the offsets
and indeed also the Positioning Models, etc. This may be what you're
driving at?
No, it's not a matter of scripting. Someone designing a page can alter
your definitions by overriding them with their own style definitions
later in the cascade.

I mean something that has analogs elsewhere in the software world. For
example, in object oriented (OO) design, when you add methods to a
class, can make a method virtual, while providing a definition for it.
This allows someone who derives a class from yours to provide an
alternative definition for his version of the method. He doesn't have
to, but he can. On the other hand, if you don't want your method
overridden, you can make it nonvirtual.

If you're the only one who's going to be deriving classes from your base
class, it makes no practical difference whether you make the method
virtual without overriding it, or make it nonvirtual. So why have a
distinction between virtual and nonvirtual methods? The reason lies in
the ability to enforce policy: If others are going to have access to
your class and will be able to derive from it, you make the decision
between virtual and nonvirtual according to whether you want to *allow*
them to override your methods.

This latter scenario doesn't exist in the CSS setting. In the OO
setting, the person creating the derived class doesn't have the ability
to alter the definition in the base class. With CSS, any person who can
change the offsets, can just as easily change the display property. So
the rationale for having both virtual and nonvirtual methods in OO is
inapplicable to the availability in CSS of both relative positioning
with no offsets and static positioning.
Sep 7 '06 #26

P: n/a
Well, let me thank everyone who's participated in this thread for hanging in
there with me.

I got started on this whole exercise because I wanted to finally gain a
thorough understanding of positioning by experimenting with the various
options, and right out of the box I hit this odd rule that we've been
discussing here. As it turns out I think I have gained a pretty thorough
understanding of positioning, although the process wasn't as I expected.

Ultimately I think that the answer to the basic question of *why* it is this
way is left unanswered. A couple of theories have been put forward, but
nothing seems definitive.

So I'm done with positioning for the time being. Now, on to floats. You'll
probably be hearing again from me shortly.
Sep 7 '06 #27

This discussion thread is closed

Replies have been disabled for this discussion.