Question about positionning.

Hello.

I observed something strange in Firefox which let me study precisely the
section 10.3.7 of the specifications of CSS2 and I have a question about it.

The specifications refer to a special value "static-position" which is
defined as the value a hypothetical box would have when positionned with
"static" argument.

But the position of such a hypothetical box depends on some properties
of the hypothetical box : for example, is this box displayed inline or
as a block ? Has it a null width ?

How is it interpreted usually ?

Thank you.

Sylvain Chevillard

On 2006-11-14, Sylvain Chevillard <sylvain.chevillard (AT) wanadoo (DOT) fr> wrote:

Hello.

I observed something strange in Firefox which let me study precisely the
section 10.3.7 of the specifications of CSS2 and I have a question about it.

The specifications refer to a special value "static-position" which is
defined as the value a hypothetical box would have when positionned with
"static" argument.

But the position of such a hypothetical box depends on some properties
of the hypothetical box : for example, is this box displayed inline or
as a block ?

Good question. Firefox, Opera and Konqueror all take into account
whether the box was originally inline or block, which seems the most
appropriate thing to do.

Has it a null width ?

It seems that the hypothetical box's width is considered to be zero. The
only time a box's width affects its position is if the box is floated or
inline, where it might not fit in the space available and so get moved
down.

But that's expecting the browser to take the hypothesis a bit far I
think, and none of the three I tried do.

Relying on the static position for absolutely positioned boxes is a bit
risky, especially as the spec says the browser is free to "guess" where
to put them. It's especially risky if they are/were inline or floated.
For a block box it's pretty easy for the browser to say where it would
have gone.

Sylvain Chevillard wrote:

Hello.

I observed something strange in Firefox which let me study precisely the
section 10.3.7 of the specifications of CSS2 and I have a question about
it.

The specifications refer to a special value "static-position" which is
defined as the value a hypothetical box would have when positionned with
"static" argument.

Not an accurate quote at all. This is it:
The term "static position" (of an element) refers, roughly, to
the position an element would have had in the normal flow.
Your hypothetical static box cannot be positioned. It does not take
positioning properties (top, left, right, bottom).
Your static box will always be in "flow" - as if no CSS were used.

But the position of such a hypothetical box depends on some properties
of the hypothetical box : for example, is this box displayed inline or
as a block ? Has it a null width ?

Again, a static box cannot be positioned - it does not take positioning
properties.
A static block initially is a block and as such takes dimension
properties (width, height). If none is given, then it has the full width
of the container, even if its inherent width is less.
A static block defined as inline (display:inline does not take
dimension properties. It has the element's inherent width (such as
text). If none, then it is none.

--
Gus

Gus Richter wrote:

Sylvain Chevillard wrote:
Hello.

I observed something strange in Firefox which let me study precisely
the section 10.3.7 of the specifications of CSS2 and I have a question
about it.

The specifications refer to a special value "static-position" which is
defined as the value a hypothetical box would have when positionned
with "static" argument.

Not an accurate quote at all. This is it:
The term "static position" (of an element) refers, roughly, to
the position an element would have had in the normal flow.
Your hypothetical static box cannot be positioned. It does not take
positioning properties (top, left, right, bottom).
Your static box will always be in "flow" - as if no CSS were used.

But the position of such a hypothetical box depends on some properties
of the hypothetical box : for example, is this box displayed inline or
as a block ? Has it a null width ?

Again, a static box cannot be positioned - it does not take positioning
properties.
A static block initially is a block and as such takes dimension

A static block defined as a block (display:block takes dimension

properties (width, height). If none is given, then it has the full width
of the container, even if its inherent width is less.
A static block defined as inline (display:inline does not take
dimension properties. It has the element's inherent width (such as
text). If none, then it is none.

Correction as per above. Also note that the specifications outline which
element is inline or block, or the display property may redefine it.

--
Gus

Thank you both for your answers.

Gus Richter: when I said "positionned with static argument", I meant
"positionned by the user agent" not by a CSS left or right argument. I
was not clear about it. Please excuse me. Ben C has understood my
thought and pretty well answered.

Ben C: there is another time where the width affects the position of an
element in the flow, and that is the situation I encountered. If your
element is in a text-align:center environment, and if its actual
computed width is w and the center of the parent block is c, the left
edge of the element will be c-w/2.
My personal understanding of the idea behind the specifications is that
an element with position:absolute and no left/right indication should be
horizontally positionned as if it were in the normal flow. This lets you
for example position an element absolutely vertically but let it stay in
the normal flow horizontally.

With that understanding of the specifications, it is clear that the
hypothetical box should have the same computed width that my element, so
my absolutely positionned element would keep centered in the page.

Do you agree with my opinion ?

Sylvain Chevillard

On 2006-11-15, Sylvain Chevillard <sylvain.chevillard (AT) wanadoo (DOT) fr> wrote:

Thank you both for your answers.

Gus Richter: when I said "positionned with static argument", I meant
"positionned by the user agent" not by a CSS left or right argument. I
was not clear about it. Please excuse me. Ben C has understood my
thought and pretty well answered.

Ben C: there is another time where the width affects the position of an
element in the flow, and that is the situation I encountered. If your
element is in a text-align:center environment, and if its actual
computed width is w and the center of the parent block is c, the left
edge of the element will be c-w/2.

Good point.

My personal understanding of the idea behind the specifications is that
an element with position:absolute and no left/right indication should be
horizontally positionned as if it were in the normal flow. This lets you
for example position an element absolutely vertically but let it stay in
the normal flow horizontally.

With that understanding of the specifications, it is clear that the
hypothetical box should have the same computed width that my element, so
my absolutely positionned element would keep centered in the page.

Do you agree with my opinion ?

Yes. I think that's a better interpretation and can't see any argument
against it other than that it's more hassle to implement.

Unfortunately the implementors of Firefox and Opera haven't bothered.
Firefox does c - w/2 but treating w as 0, Opera just leaves the inline
box at the left margin.

But what they're doing is OK because the spec says they are free to
guess the position of this box.

In fact if what you're suggesting did work reliably it would be a way to
centre a shrink-to-fit block box without using inline-block, table or
table-cell. That would be quite a discovery.

You can of course use position: relative, which will preserve centering
as the box is still in the flow and inline, and then apply a vertical
offset, but it's relative to the box's normal flow position not its
container, which may not be convenient.