Stylesheets - Question about positionning.

Author

Question about positionning.

Sylvain Chevillard

2006-11-19, 7:36 pm

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

Ben C

2006-11-19, 7:36 pm

On 2006-11-14, Sylvain Chevillard <sylvain.chevillard@wanadoo.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.

Gus Richter

2006-11-19, 7:36 pm

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

2006-11-19, 7:36 pm

Gus Richter wrote:
> Sylvain Chevillard wrote:
>
> 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.
>
>
> 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

Sylvain Chevillard

2006-11-19, 7:36 pm

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

Ben C

2006-11-19, 7:36 pm

On 2006-11-15, Sylvain Chevillard <sylvain.chevillard@wanadoo.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.