All users were logged out of Bugzilla on October 13th, 2018

absolute position within relative postion displays oddly

REOPENED
Unassigned

Status

()

REOPENED
18 years ago
a year ago

People

(Reporter: vague, Unassigned)

Tracking

({css2, testcase})

Trunk
x86
Linux
css2, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME, URL)

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; 0.8) Gecko/20010218
BuildID:    2001021812

When you enclose an absolutely positioned element, with "auto" top and 
left, within a relatively positioned element, the absolutely positioned
element doesn't appear anywhere near the relatively positioned element

Reproducible: Always
Steps to Reproduce:
You can download the file,

http://fluffyland.cx/projects/webnote/test_content_with_note.html

and display it under X-windows mozilla.  I haven't tried to reproduce
under windows.

Actual Results:  The step above pretty much describes the bug.

Expected Results:  The absolutely positioned element should have been
displayed next to the relatively positioned element (from my reading of
the CSS-P standard)

The CSS-P standard seems a little vague about what should happen
with the "auto" properties of an absolutely positioned element. I'd
like it to appear above/next to content in the HTML file.

Comment 1

18 years ago
Pretty sure this is a dupe. Will come around for another pass later. Get setup
for your attack run...oh sorry momentarly over come by Star Wars imagery.
Whiteboard: DUPE ME
OK... I've looked at the URL provided.  It has <span> elements which are being
positioned, which obviosly has no effect.

Stephen Rosman, could you attach a testcase that actually demonstrates the bug?
(Reporter)

Comment 3

18 years ago
I have to admit I was drunk when I submitted this bug
but in the cold hard light of day it's still there and
the URL does demonstrate it.  (I just don't think I
explained it well)

From my reading of what the "auto" value of an absolutely
positioned element is meant to do, it should place the
"auto" positioned element at the position on the page that
it was up when it came across the element, it should just
float "above" the page at that point and not interrupt the
flow of the document which is "underneath" it.

Mozilla currently postions the element correctly vertically
but horizontally it places the "auto" positioned element at
the start of the line (the left-most extreme of the containing
box)

While I was trying to find a way around this, I tried putting
the "auto" absolutely positioned element inside a relatively
positioned element.

Although it did appear to position itself correctly horizontally,
it positioned itself approximately twice as far down the page
(vertically) as it should have.

(If you're wondering why I want to do this (or can offer a work-
around) I want to build web-postit notes by having a proxy parse
an html page and insert "layers" at specific points in a document
where an editor may have a comment.  Of course a pixel positioned
layer won't work since a differently sized/platformed/font-sized
web browser won't have a piece of text at the same place.)
Stephen, I'm attaching a screenshot of what I see on that page.  The only
positioned elements are the span containing "ACTblah?OR" and the span containing
"blah?".  Being spans the of course ignore positioning completely.  Are we
talking about the same page here?

Comment 6

18 years ago
Positioning applies to all elements, except generated content. However, the 
display property of an element with 'position:absolute' will be set to 
'display'.
http://www.w3.org/TR/REC-CSS2/visuren.html#q24

And I believe inline relatively positioned element can be a containing block for 
an absolutely positioned element, the difference being that the containing block 
is formed by the content edge rather than the padding edge.
http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details


However, what was puzzling me about the test URL was that the Abs Pos element 
appeared to be missing - all I was getting was the Rel Pos span.

Then I noticed if I made the window large enough it did appear, but way down the 
page - nowhere near in the Rel Pos SPAN.

So there seem to be two bugs here:

1. The Abs Pos element is only being rendered only if it is present in the 
window on load; if one has to scroll down to it, it will not be rendered.

2. And what seems to be the current bug - that the position of the Abs Pos 
element is wrong. What I notice with this is that the top position of the Abs 
Pos element is roughly twice what it should be, as if the offset of the Rel Pos 
element is being used twice to calculate where to render the Abs Pos element. 
This remains true no matter where one positions the Rel Pos element. The left 
position seems to have what may be the BODY margin added twice - I'm not sure.

Example. The following attachment contains:

  <p>text<br>text<br>text<br>text</p>
  <p>
   <span class="container-red" onmouseover="alert('Rel Pos SPAN is here')">Rel 
Pos SPAN
    <span class="abspos-blue" onmouseover="alert('Abs Pos SPAN is here')">Abs 
Pos SPAN</span>
   </span>
  </p>

with the following style:

  .container-red {position:relative; border:2px solid red;}
  .abspos-blue {position:absolute; background:#aaccdd;}


I included the alerts on mouseover to also show that the Abs Pos element doesn't 
behave properly. Notice that the mouseover has no effect.

Comment 7

18 years ago
Created attachment 35309 [details]
testcase - inline REL POS element containing ABS POS element

Comment 8

18 years ago
I've just noticed that my attached testcase behaves differently online - the ABs 
Pos element is absent from the start, and even on reload. But forcing a repaint 
by resizing the window will make it appear.

BTW, I'm using build 20010505115 in Win98.

Comment 9

18 years ago
Changing QA contact
QA Contact: petersen → ian

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

17 years ago
not table specific, reassigning to core owner.
Assignee: karnaze → attinasi
QA Contact: ian → petersen

Comment 11

17 years ago
Stephen, if you are trying to get a psot-it kind of effect, you could try using 
the title attribute, so when you mouseover, the pop up would display with the 
comment.

Comment 12

17 years ago
adding the css experts for some advice on this one
There's definitely something wrong here, probably in all the code Troy (?) wrote
to deal with positioning inside of a relatively positioned inline element.

Updated

17 years ago
Target Milestone: --- → mozilla1.1
Keywords: testcase
Keywords: css2

Comment 14

15 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future
.
Assignee: attinasi → position
Component: Layout → Layout: R & A Pos
QA Contact: petersen → ian
Target Milestone: Future → ---

Comment 16

15 years ago
This now mostly works, due to roc's checkin from bug 235778. There are still
perhaps issues with the left/top: auto positioning.

*** This bug has been marked as a duplicate of 135082 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
This case is still not quite right; remaining issues are tracked in bug 5016
Depends on: 5016

Comment 18

14 years ago
Created attachment 154318 [details]
Documents a reliable failure caused by <p style=margin-left:3mm> or  <p style=text-indent:3mm> (3mm or any other nonzero displacement) It goes away after the </p>. 

The failure succeeds, so to speak, on six out of seven browsers I run.	It
causes the seventh (NN4) to forget what font it was using (one of my
favorites).  I am running windows XP-home, and will check out windows NT next
week.

Comment 19

14 years ago
(In reply to comment #18)
> Created an attachment (id=154318)
> Documents a reliable failure caused by <p style=margin-left:3mm> or  <p
> style=text-indent:3mm> (3mm or any other nonzero displacement) It goes away
> after the </p>. 
> 
> The failure succeeds, so to speak, on six out of seven browsers I run.	It
> causes the seventh (NN4) to forget what font it was using (one of my
> favorites).  I am running windows XP-home, and will check out windows NT next
> week.


A note to myself:

Item 1: Same things happen on windows NT. 

Correction: margin-left:# appears to be all right after all.  No misalignments
after either <p style=margin-left:#> or <a style=margin-left:#>.  (#!=0)

Item 2: Misalignment of some absolute displacements occurs after either
<p style=text-indent:#> or <a style=text-indent:#>.  Would that be an AHA?
I don't know.
Assignee: layout.r-and-a-pos → nobody
QA Contact: ian → layout.r-and-a-pos

Updated

8 years ago
Whiteboard: DUPE ME → DUPEME
You need to log in before you can comment on or make changes to this bug.