168971 - [ABS POS]position without positioning doesn't consider 'float' property

Status: RESOLVED INVALID

(Core :: Layout: Positioned, defect, P4)

Description

[Denny De La Haye]

User-Agent:       Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020606
Build Identifier: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020606

This page looks completely bizarre in Mozilla and Galeon.  The main style
element used seems to be [div].  The page validates as HTML 4.01 Strict and CSS2
compliant using the W3C and WDG validation services.

Reproducible: Always

Steps to Reproduce:
1. Visit the page.
2. Admire the weirdness.

Actual Results:  
Odd rendering.

Expected Results:  
Legible rendering?

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The biggest issue seems to be about 'position: absolute' not respecting the old
value of 'float' when determining what the position would be without absolute
positioning -- this is an ambiguity with section 9.7 of CSS2, but I think it's
been resolved to say that we're wrong, at least with other changes to Mozilla.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(The main problem I see is that what is supposed to be on the bottom right is
instead on the bottom left, overlapping other things.  That would be fixed by
removing the extraneous 'position: absolute', but I think we should be putting
it on the right, anyway, although the issue is very complicated.

Are there other things you observed as wrong with the page?  (If there is a
browser that you think displays it correctly, could you attach a screenshot?)

Comment 3

[Denny De La Haye]

Attachment: Screenshot of Netscape Navigator 4.78

This shows the content appearing in the right place re: the right hand column,
but obviously it's lost almost all other style info as Navigator 4.x is fond of
doing...

Comment 4

[Denny De La Haye]

Attachment: Screenshot of Opera 5.05

Viewed using Opera you can see that Mozilla and Galeon are also not rendering
the top half of the page as the author probably intended - the Opera rendering
of this looks more likely to be correct.  Bottom half is still wonky in Opera
though, with the right on the left as in Mozilla and Galeon...

Comment 5

[Madhur Bhatia]

Attachment: minimized testcase

1. The left DIV (float to left) is overlapped with the right DIV (float to
right).
2. The left DIV width (<percentage>)and height(<length>) is not rendering
3. the main DIV height (auto)is not rendering
4. "background-position : right bottom" not rendering

tested this on 
platform : win 2000 
build : 2002-09-12-trunk

Comment 6

[Madhur Bhatia]

confirming this bug 
changing plaftform to all , since i see this in win2000 as well
adding keyword 'testcase'
adding priority "[QA-P2]" to status whiteboard.

Comment 7

[Madhur Bhatia]

Attachment: the correct testcase

please see this testcase instead of attachment 99402 [details]. This testcase shows the
image with style "background-position: right bottom".

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For the background-image issue, Mozilla is correct and Opera is wrong --
background images with 'background-attachment: fixed' (which the author did not
intend) are positioned relative to the viewport.  I think this page would appear
much better if the author removed 'position: absolute' from the rule with
selector #right (also not intended, but a very obscure issue where Mozilla's
behavior is not correct) and 'background-attachment: fixed'.

In any case, I'm making this bug about the one issue that I believe is valid
(albeit very obscure and thus minor).  If you think there are any other valid
bugs shown by this page, please file separate bugs.

Comment 9

[Mats Palmgren (inactive)]

Attachment: Testcase, position:absolute + float:right

Simplified the "position:absolute" case even further.

dbaron: so what you are saying is that we should take top/left from the
position
the box would have had before 'float' was set to 'none' (CSS2 9.7)?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Maybe.  I'd rather not have to bother, though, and we should probably get the
spec clarified for CSS 2.1.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Taking.  Need to discuss with WG.

Comment 12

[Eli Friedman]

This is clarified in CSS2.1.  10.3.7 and 10.6.4 define the position only based
on the the position the element would have had in normal flow.  I think this
means that the float property should not be considered in calculating an
absolutely positioned block's position, as floats are outside normal flow.

If my interpretation is correct, this bug is invalid, but bug 237770 is valid.

Comment 13

[Eli Friedman]

Okay, the current version is crystal clear:

The static position for 'left' is the distance from the left edge of the containing block to the left margin edge of a hypothetical box that would have been the first box of the element if its 'position' property had been 'static' and 'float' had been 'none'.

and

More precisely, the static position for 'top' is the distance from the top edge of the containing block to the top margin edge of a hypothetical box that would have been the first box of the element if its 'position' property had been 'static' and 'float' had been 'none'.

Therefore, this bug is invalid.