Closed Bug 274387 Opened 20 years ago Closed 20 years ago

div top margin incorrectly applied to earlier sibling absolutely positioned div

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ray, Unassigned)

References

(
URL
)

Details

(Keywords: qawanted, testcase)

Attachments

(2 files, 2 obsolete files)

Corrected testcase.
422 bytes, application/xhtml+xml
Details
Sure thing. Testcase for auto-width float example.
582 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041212

In the above URL the "Jigsaw" image appears too low, on top of the heading text.
The simple example (j.html) below shows the two div texts t1 and t2 on smae
horizontal line.
t1 should be at top left but has been moved down to be in line with t2.

Reproducible: Always
Attached file simple example (obsolete) — 

    
    

    
  
Confirming.
This is not a recent regression, I can see the bug even in Mozilla1.4 (before
that, more things are going wrong).

Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
*** Bug 200944 has been marked as a duplicate of this bug. ***
Keywords: testcase

    
    

    
  
Er... isn't this the right behavior?  The margin collapses with the body margin,
which pushes down the placeholder for the auto-offset absolutely positioned div.

Just putting a border on the body will prevent margin-collapse here and put the
div in the "right" place.

Ian, what's the right collapsing behavior here?
Keywords: qawanted

    
    

    
  

      
      
      
      

        Attached file
          
        Same testcase, but in standards mode (obsolete)
        — 
      

    


  
Well, according to:
http://www.w3.org/TR/CSS21/box.html#collapsing-margins, the 4th list-item:
"Margins of absolutely positioned boxes do not collapse (not even with their
in-flow children)."
I don't expect a margin collapse here. Opera7.54 doesn't do margin collapsing
here, so I think it is a bug of Mozilla.

    
    

    
  
Comment on attachment 171478 [details]
Same testcase, but in standards mode

Fixing MIME type. Please don't use XHTML unless you use the XHTML MIME type,
it's just confusing otherwise.

        Attachment #171478 -
        Attachment mime type: text/html → application/xhtml+xml

    
    

    
  
(as demonstrated by the fact that when you fix the MIME type the testcase breaks).

    
    

    
  
Anyway, the correct rendering (when you fix the testcase to use correct
selectors) is somewhat undefined, since it relies on the definition of "static
position", which is left up to UAs (UAs are allowed to guess). The ideal
position would be that the first <div> (the positioned one) is about 180px from
the second one, because if it wasn't positioned, that's where it would be.

Mozilla's rendering is incorrect per this ideal, because it is positioning the
<div> as if it was a float, not as if it was a static in-flow box.

    
    

    
  

      
      
      
      

        Attached file
          
        Corrected testcase.
        — 
      

    


  

        Attachment #168597 -
        Attachment is obsolete: true

        Attachment #171478 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 171491 [details]
Corrected testcase.

Opera 8.0 beta does indeed render this correctly.

    
    

    
  
Who said anything about the margins of the abs-pos div collapsing?  The margins
of the div with a margin set are what collapse.

There's a circular dependency here -- if the abs pos div were static pos, the
margins would not collapse, and the <body> top content edge would be in a
different place from where it actually is.  But as things stand, we're placing
the "this is t1" at the position of the first line box in the <body>

Ian, what makes you say that Opera's behavior here is correct?  Should the "this
is t2" div's margin not collapse with the body margin?

    
    

    
  
Ok, I see what Hixie's saying about "as if it were a float".

The way Mozilla implements the verbiage about "as if it had static position" is
by laying out all in-flows (which it has to do anyway) and then looking where in
the resulting document the box would have been if it had static position.  In
this case, that leads to the observed layout, of course.

The alternative would be to actually do an extra reflow of everything for every
auto-offset abs pos element that you have around.  This would be needed, to get
that "ideal" rendering, in the case of an auto-width parent float whose width
would be affected by the abs pos element if it were static pos such that the
float would no longer fit where it's placed currently (Ian, does Opera get this
"right"?).

This approach is really quite inefficient, and I question the "ideal" being put
forth here.  Given that the language in the specification is there for compat
with IE, I think simplicity of specification is being prized over simplicity of
implementation here...  It may be worth revisiting what the specification says
with an eye towards simpler and easier to understand behavior.

    
    

    
  
Could you attach a testcase for your example? I don't really follow.

    
    

    
  
So to answer my own question, Opera 8.0 Beta 1 on Linux gets my testcase "wrong".

    
    

    
  
I'm marking this INVALID since the spec gives us latitude here.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: