22171 - [FLOAT] misplaced form widgets inside absolutely positioned DIV

Status: VERIFIED WORKSFORME

(Core :: Layout, defect, P3)

Description

[John Morrison]

This bug is split off from bug #21560 (See other related bugs for the same
URL as bug #22168 and bug #14030 -- http://www.espn.com/ has several problems).

This bug addresses a problem with 'misplaced form widgets inside absolutely
positioned DIV' at the top of the viewport. The form widgets in the original
page are partially obscured by another absolutely positioned DIV that overlaps
the first DIV. In the reduced test case (to be attached), I have moved that
second DIV lower on the page. Further comments inside the attachment.

Comment 1

[John Morrison]

Attachment: testcase; misplaced form widgets inside of DIV

Comment 2

[John Morrison]

Attachment: screenshot; www.espn.com (12/19/99)

Comment 3

[karnaze (gone)]

Reassigning to Rod.

Comment 4

[rods (gone)]

Attachment: Simplified testcase

Comment 5

[rods (gone)]

For some reason the form (which is a block frame) is being positioned 17 pixels
lower than it should. Why?

Comment 6

[rods (gone)]

I think it is a generic frame layout problem for these reasons:
1) The form frame is a block frame and it does not do any reflow.
2) If I change the "form" tag to a "p" tag it exhibits the same behavior.

What is interesting is that if I change the "form" tag to a "div" tag it lays
out correctly.

Reassigning to Troy (could be a Kipp line layout issue)

Comment 7

[troy]

Sounds like a block issue

Comment 8

[buster]

mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.

Comment 9

[Hixie (not reading bugmail)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 10

[Hixie (not reading bugmail)]

This has now been fixed. The problem was that FORM (and P) elements had 1em
top margin, which is not backwards-compatible. This has now been removed, and
FORM elements only have 1em bottom margin.

Marking WORKSFORME. It's really a DUP of the "form elements have non backwards
compatible margins" bug but I can't remember that bug's number off hand.

Comment 11

[John Morrison]

Yep. That would be the fix per discussions on 16253 "{compat} FORM margins not 
backwards compatible". Marking VERIFIED. Thanks.