Poor Positioning when Position:absolute or Position:relative used without a specified location




Layout: R & A Pos
16 years ago
16 years ago


(Reporter: John Scogin, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216

When using Position:absolute or Position:relative in a <div> or <span> structure
and no location is specified, the text should follow the normal layout pattern.
 However, in several cases, the placement of the text in the <div> or <span>
structure  is not correct, most of the time it is too low, but occasionally it
is too high.

I have provided a testcase in the steps to reproduce section.  I have tested the
behavior in Moz.1.0.2, Moz.1.2.1, Netscape4.73, and IE5.  

Problem 1.  Moz.1.2.1 does not have the same layout as Moz.1.0.2. Spefically,
the behavior of line #okra in Moz.1.2.1 is odd.  It is too high, overlapped the
text above, and somewhat offset to the right.  This is not the same behavior as
in Moz.1.0.2.

Problem 2.  Most text lines overlap the text below them.

IE5 seems to come the closest to rendering as expected.    

Reproducible: Always

Steps to Reproduce:
  <title>Position: Absolute; and Relative; in &lt;div&gt; and &lt;span&gt;
Layout Test</title>
     <span style="position: relative;">Banana * (ok-all)</span><br>
     <span style="position: absolute;">Carrot * (x-Moz1.0.2 ok-Moz1.2.1 ok-IE5 
<div style="position: relative;">Fig * (x-Moz1.0.2 x-Moz1.2.1 x-IE5 x-NS4.73)</div>
<div style="position: absolute;">Honeydew * (x-Moz1.0.2 x-Moz1.2.1 ok-IE5 
<div style="position: relative;"> <span style="position: relative;">Lime
* (x-Moz1.0.2 x-Moz1.2.1 x-IE5 x-NS4.73)</span></div>
<div style="position: relative;"> <span style="position: absolute;">okra
* (ok-Moz1.0.2 x-Moz1.2.1 ok-IE5 x-NS4.73)</span></div>
<div style="position: absolute;"> <span style="position: relative;">Plum
* (x-Moz1.0.2 x-Moz1.2.1 ok-IE5 x-NS4.73)</span></div>
<div style="position: absolute;"> <span style="position: absolute;">Strawberry
   * (x-Moz1.0.2 x-Moz1.2.1 ok-IE5 x-NS4.73)</span></div>

Actual Results:  
1. In Moz.1.2.1, line #okra is raised into the line above.  

2. Most lines modified by the <div> or <span> overlap the line below. Some lines
(line #lime and #fig) create blank lines, which may be the correct behavior in
these cases. 

Expected Results:  
1. Moz.1.2.1 should place line #okra in the same manner as Moz.1.0.2

2. Text should be in a single uniform column.  (Well ok, lines #fig and #lime
may actullly be rendered correctly.)

Ok, why would you code this way?  I don't have a clue.  The testcase is cut down
from a large page in use where I work.  It has lots of styles, popup menus, a
clock, and some other junk in it.  Several styles are used to create the layout,
some of which use these odd positionings.

The page worked fine in Moz.1.0.x, but it fails in Moz.1.2.1.  Since all of list
elements are actually links, when they overlap I cannot access the link on the
bottom.  The odd behavoir of Moz.1.2.1 prevents me from using it for my browser
at this site.

Comment 1

16 years ago
First, you should understand, that IE think that he is clewer than webmaster,
and try to "resolve" all overlaps -- invalidate standarts, of cource. Secondary,
what do you think positioning do? Let me paste it:


    The box's position is calculated according to the normal flow (this is
called the position in normal flow). Then the box is offset relative to its
normal position. When a box B is relatively positioned, the position of the
following box is calculated as though B were not offset. 
    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. Absolutely positioned boxes are taken out
of the normal flow. This means they have no impact on the layout of later
siblings. Also, though absolutely positioned boxes have margins, they do not
collapse with any other margins.

So if you remove all position:absolute blocks, you could see normal text (IE and
Mozilla doing almost same on it). Then, when we insert ansolute pos. blocks,
they are "Absolutely positioned boxes are taken out of the normal flow. This
means they have no impact on the layout of later siblings.", so if you don't
specify their margins, they SHOULD colapse with previous text.

So, <span style="position: absolute;">Carrot * should go into left-topmost
corner and should overlap Apple.

For close inspection, you could consult

Comment 2

16 years ago
Oh, btw, what is wrong with okra? I see it between Nectarine and Orange, in
Mozilla 1.3b and IE 6.0. Maybe it was 1.2.1 bug?

And all other text seems owerlaps as specified in CSS2 specification: contained
block for Honeydew start after "Grape", and kivi should overlap it. "Lime" in
normal float and should not overlaped, "okra" inside div with normal flow, size
of this div calculated from size of span with okra, so it should not overlap.
span witn plum and strawberry included in absolute positioned div's, so they
overlap by next item. 

Comment 3

16 years ago
Created attachment 111412 [details]
position:absolute lead text to overlaping
Testing with moz 1.0.2 is not useful, since it's no longer being actively
developed....  Further, it had some positioning bugs which were fixed in 1.2.1
(these account for the vast majority of the differences you list).

Looking into the 1.2.1 issues, the #okra problem is bug 181644.

All the overlaps I see are correct; if you have an absolutely positioned element
it does not take up any space; whatever came after it in the source should, if
not positioned itself, overlap it.

I'm marking this dependent on bug 181644, but it looks like a straight duplicate
to me... (and will be fixed in 1.3).
Depends on: 181644
Just as a further note, the text in comment 1 about 'So, <span style="position:
absolute;">Carrot * should go into left-topmost corner' is wrong.  It should
not.  The fact that it does in a current nightly is bug 187749, which will be
fixed in 1.3 (hopefully in 1.3b, in fact).  The only overlaps that should be
happening are absolutely positioned elements overlapping the text that comes
right after them; they should not be overlapping the text before them.

Comment 6

16 years ago
Hmm... I see, it should overlap Date.

Comment 7

16 years ago
In Moz.1.3.b Mozilla 1.3b (Gecko/20030113) the display of the Line #okra is what
was expected.  Thanks for pointing out the other bug, I missed it when I was

Comment 8

16 years ago
Sorry, about comment #6. I was wrong. Carrot should not overlap anything.
This code should be visible as, because span could take place after empy line,
created by <br> tag (div could not)

first line      text 
second line     ""<span position:absolute>
third line      text

Fixed by bug 181644
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.