Closed
Bug 86844
Opened 23 years ago
Closed 23 years ago
Setting marginheight and marginwidth on body element screws up input element coords
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: marka, Assigned: pierre)
Details
Attachments
(3 files)
Build ID: 2001061721 Setting marginheight and marginwidth on body element screws up input element coords. Attached test case will follow.
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
Changed summary.
Summary: Setting marginheight and marginwidth on body element screws up input element coords → marginheight and marginwidth needed on body element in order to get correct input element coords
Reporter | ||
Comment 3•23 years ago
|
||
Reporter | ||
Comment 4•23 years ago
|
||
Description of test page: ========================= The test page just draws a red rectangle (div element with 5px border) over the input element when the mouse is over it. The rect goes away when the mouse leaves the drawn rectangle. The bug: ======== This page needs marginheight and marginwidth on the body element in order to get the correct input element coords. Test case: ========== Test with and without the marginheight and marginwidth.
Reporter | ||
Comment 5•23 years ago
|
||
Aarg! This mozilla nightly seem to have a cache problem or something, I've been using the reload button and seen quite a few problems there with some old page content showing up in the new one etc. I'm not sure that this bug is valid, I will have to run the tests again.
Comment 6•23 years ago
|
||
So... is the behavior "correct" in your opinion when marginheight and marginwidth are set to 0? Or when it's not? The statements you make at "2001-06-20 05:11" and "2001-06-20 05:32" are not consistent with each other. Could you attach a screenshot of what you consider to be correct behavior? See also bug 81290, bug 34398, bug 60935
Component: HTMLFrames → Style System
Reporter | ||
Comment 8•23 years ago
|
||
Changed summary back to original one. I guess I was a bit confused earlier on. Let's see if this makes sense: What I said "2001-06-20 05:11" is correct, i.e. it is with the first test case I believe there must be a problem. Try to ignore what I wrote about the second test case and "2001-06-20 05:32" :) Anyway, what I wanted to do was to draw a rect around (using border) the currently focused link. This works just fine in almost all cases. However, when I set marginheight and marginwidth to zero on the body element, I do not get the correct coordinates using offsetLeft, offsetTop for an input element on the test case. The attached test case (first one!) has marginheight and marginwidth set on the body element. Thus, this generates the incorrect behaviour. If these attributes are removed, the page works the way it should. The attached image below shows this. The upper snapshot is with marginheight and marginwidth. The bottom one is without these attributes.
Summary: marginheight and marginwidth needed on body element in order to get correct input element coords → Setting marginheight and marginwidth on body element screws up input element coords
Reporter | ||
Comment 9•23 years ago
|
||
Comment 10•23 years ago
|
||
OK. Looks like the problem here is that offsetLeft/offsetTop give the coordinates relative to the viewport while the left/top CSS properties give coordinates relative to the containing block. That's bug 81290. Marking duplicate; please reopen if you disagree. *** This bug has been marked as a duplicate of 81290 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 11•23 years ago
|
||
Hmmm...just had a look at bug 635. marginwidth and marginheight cannot be set on the body tag according to the HTML 4 spec. Though they can on nav 4.x. Does that really make this bug invalid? I mean, in that case nothing should happen when using them, or?
Comment 12•23 years ago
|
||
we support those attributes in backwards-compatibility mode.
You need to log in
before you can comment on or make changes to this bug.
Description
•