Absolutly positioned divs with haight and width and containing an image is positioned wrong




17 years ago
17 years ago


(Reporter: dama, Assigned: attinasi)


Windows 2000

Firefox Tracking Flags

(Not tracked)





17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

The lines should meet at the ends but they do not.
The images seems to have an extra offset depending on size?

Check the page reference for an better description.

Also. the javascript text scroller does not work any more.

It all worked before I remade the page to conform with W3 standards?

This could be related to Bug 97777 but the problem is not exactly the same.

Reproducible: Always
Steps to Reproduce:
Check http://www.lillmicke.nu

This page validates correctly on both HTML 4.01 strict and css 
(test w3 links)

Actual Results:  Images is offset about 1/2 cm left or up.

Expected Results:  The line ends should meet and no picture should overlap.

Above the top line letters should be dropping in from the side to
form the word lillmicke.nu

Comment 1

17 years ago
dup of bug 22274?
Not sure, but it's not a DOM problem...
Assignee: jst → attinasi
Component: DOM HTML → Layout
QA Contact: stummala → petersen

Comment 3

17 years ago
changing the qa contact and owner 

Comment 4

17 years ago
If this bug is found to be a dup for bug 22274 then there must be something wery
vrong since it passes w3c's validation for HTML 4.01 Strict and the css level 2

Also, if I have two absolutly positioned layers with the following values

<div style="position:absolute; left:0px;   top:200px; width:480px; height:1px;">
 <img alt="horizontal-line" src="images/black-pix.gif" style="width:480px;
height:1px;" width="480" height="1">

<div style="position:absolute; left:480px; top:200px; width:1px; height:60px;">
 <img alt="vertical-line" src="images/black-pix.gif" style="width:1px;
height:60px;" height="60" width="1">

The first should end on the right side at the exact position the next starts
even if the offset from page 0,0 is wrong. I meen that the layers should not
have a different offset from each other. Or?

Any rendering where the ends do not meet must be considered wrong.

This works fine in both IE 5.5 sp1 and Opera 6.

Comment 5

17 years ago
I'm Sorry for the spam. (Listed this on the wrong bug, sorry)

I tested the rest of the pages below the start and they work fine so the 
problem must have something to do with mozillas implementation of HTML 4.01 Strict.

(except for some minor alignement problems with the other images but thats
probably my code)

Comment 6

17 years ago
I tested with the explanation from bug 22274 and setting img {display:block;} did 
solve the problem.

This must mean that setting size absolutly and including an image is a bad idea,
I suggest you send this information to w3c and ask them to clarify how they
intended it to work and if your implementationis correct that they include an
warning for this problem.

I listed this as a bug of its own because bug 22274 only deals with old style
layout with tables and table cells not 
div layers and absolute positioning which is refered to as new layout that
should not have this problem.

I think this can be a big problem if more people try to use strict mode and gets
an ok from w3c's validator and also gets it to work int the other browsers.

Ask them to state how they intended it to be implemented. Mozilla should be big
enough to warrant som e attention from them : )
Am I missing something?  This is not a "new layout" vs "old layout" issue.  The
images you have were likely overflowing their container divs and being aligned
to the text baseline.  If you want images to act as blocks (as you do on the
site in question) you have to say so...

I fail to see how this differs from bug 22274.

Comment 8

17 years ago
My point in comparing with bug 22274 was that it declares the problem to be with
using table layout instead of css positioning.

This description did match my problem since I do not use tables. No where in the
first half of the document do they imply that the problem could affect anything
with absolute positioning.

I can see that in implementation this is a dup of bug 22274 but from a search
point it requires indepth analysis of bug 22274 to see the connection.

I suggest you mark this as a dup so that anyone else having the same problem can
find the solution easier

*** This bug has been marked as a duplicate of 22274 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Well it does match your problem.  The problem occurs in practice mostly with
tables, but really it is any block-level element.

On a side note, there is an article on this issue at

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