document.body.offset* returns 0.

RESOLVED WORKSFORME

Status

()

Core
DOM: CSS Object Model
P3
normal
RESOLVED WORKSFORME
18 years ago
17 years ago

People

(Reporter: Brian Sea, Assigned: jst)

Tracking

({dom2})

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.15 i586; en-US; m17)
Gecko/20000703
BuildID:    2000070308

The offset* properties of the body all return 0.  I was expecting the height,
width, etc., of the body.  Is this a bug or am I missing something?

Reproducible: Always
Steps to Reproduce:
1.
You can use code.

<html>
<head>
<script Language="Javascript">
<!--
function Test() {
window.status = "Width: "+document.body.offsetWidth+" Height:
"+document.body.offsetHeight;
}
window.onload = Test;
window.onresize = Test;
//-->
</script>
</head>
<body>
</body>
</html>

Comment 1

18 years ago
document.body.offset* is only for Microsoft IE's DHTML DOM. Moz doesn't support
this. Fun to play with though.. too bad.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

18 years ago
I understand that this isn't in the W3 standards.  It does however exist in the
Documented Mozilla DOM.  This is going to lead people to think that it actually
works, thus they can use the document.body.offset* for cross-browser coding.

This feature should either be supported correctly or, at the very least, removed
completely from the documented DOM. 

Comment 3

18 years ago
vidur@netscape.com, what say you? Is Moz supposed to support this or is just a
dream spec?

Brian - can you post the URL to that spec for future reference?

Going to reopen for us to play with...
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 4

18 years ago
I'm assuming this is the Documented DOM( correct me if I'm wrong and point me to
the right location )

http://cgi.din.or.jp/~hagi3/JavaScript/JSTips/Mozilla/idl.cgi?idl=M17&smp=y

if that doesn't work tell Me( My Cut and Paste isn't working ).

under HTMLElement:HTMLElement there exists the readonly attributes offset*
properties.

Comment 5

18 years ago
Going to go ahead and mark as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
(Assignee)

Comment 6

18 years ago
The offset properties are not defined in the W3C DOM, they were made up by
Microsoft and mozilla emulates the properties to some extent but this bug will
not be fixed for the first Netscape release.
(Assignee)

Comment 7

18 years ago
This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future

Comment 8

18 years ago
*** Bug 48956 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
*** Bug 48956 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
Adding woschwarz@gmx.de to cc list

Comment 11

18 years ago
I don't really understand why bug 48956 is a duplicate, because this one is 
about document.body.offsetHeight/Width (not dynamically written), whereas bug 
48956 is about the corresponding properties of any tag whatsoever if (and only 
if) it is created via document.write(). 
Anyway, if it is a duplicate then I think this one should be fixed - for the 
reasons I gave at Bug 48956.

Comment 12

18 years ago
I think those bugs are dups. Because the problem seems to be only at page load,
if you call for the offsetX after the page has loaded it returns the correct
value. document.write() clears all document content and "reloads" the document
with the new content. So it looks to me that this bug has nothing to do with how
offsetX is called but when.

And about the book thing... I think that it is a bad idea to use anything BUT
spec when teaching html, xml or scripting... teaching proprietary stuff defeats
the purpose of having a spec which is not just there as guide line for user
agents but, for the coders too. The W3C gives us the right way to code...
anything else is wrong, and/or lazy in my book (i love puns) :).

Comment 13

18 years ago
Sorry, but that book (which has been published 
now: http://www.javascript-workshop.de) is about how to use JavaScript in 
*existing* browsers, and you really can't do that without mentioning 
non-standard stuff. 

Anyway, the bug also affects the W3C methods. It is much more general than I 
thought. I would suggest to change the summary to:
   "impossible to read the computed size of elements before unload"

Because this does not only affect document.body, nor does it only affect 
elements creating with document.write. E.g.

<div id="test">bla</div>
<script>
alert(document.getElementById("test").offsetWidth);
</script>

also yields "0".
Nor does it only affect offsetWidth or offsetHeight, but also the cumbersome W3C 
equivalents:

<div id="test">bla</div>
<script>
alert(document.defaultView.getComputedStyle(document.getElementById("test"),null
).getPropertyValue("width"));
</script>

In effect, it forces one to delay all calculations of the computed layout to 
after onload and thus makes it impossible to dynamically build up page content 
via JavaScript. (Of course this has been noticed in javascript newsgroups like 
de.comp.lang.javascript now that N6 is released).
 

Comment 14

18 years ago
I forgot to mention the workaround. Before getting the computed height, set
   theElement.style.height = "auto";
Then you will get the right value even before onload. 
Maybe this helps to find a fix.

(Assignee)

Comment 15

18 years ago
Could someone attach some testcases here please?

Comment 16

18 years ago
Created attachment 20353 [details]
test case for all the bugs

Comment 17

18 years ago
Created attachment 20354 [details]
testcase as above, but now with the "workaround"

Comment 18

18 years ago
offsetHeight also produces zero on a div that just contains a table inside a
div. A workaround is to just add a non-breaking space between the </table> and
</div> tags

<html>
<head>
<script language="JavaScript">
function init() {
alert ("div offset" + document.getElementById("divTop0").offsetHeight);
}
</script>
</head>
<body onLoad="init()";>
<div id="divTop0" border="10" style="position:absolute; width:156;
visibility:visible">
	<table id="tt" height="100" width="100" border="1" cellpadding="0"
cellspacing="0" align="left" valign="top">
   		<tr valign="top">
  	
	 <td width="13">hello<td>
			<td>hello2</td>
		</tr>
	</table>
</div>
</body>
</html>

I have a question on this too. Since offset* is not part of the W3C standard but
IS in Mozilla, it is safe to use for development ? We are currently making our
site W3C compliant but I'm getting mixes responses on this issue. Can anyone
help, or at least point me in the right direction ? I've been advised by a W3C
author that it will not be in the standards (DOM Level 3), and he suggested not
using it. Why was it put into Mozilla in the first place ??

Comment 19

18 years ago
Three comments:

1) This bug appears to be FIXED in build 2001012020. :-) jst, have you forgotten 
to mark it?

2) Just for the sake of completeness: The bug also affected offsetLeft and 
offsetTop (as the Summary correctly says). And my workaround was too specific: 
offset* can be properly read as soon as _any_ style property of _any_ element is 
set to _any_ value.

3) Tim, your bug is different. It seems that table dimensions are ignored when 
the size of a block element (with the table as child) is computed. This is still 
around in NB2001012020. I think you should file a new bug report.

(And yes, to be strictly W3C compliant, you should not use offset* but the 
getComputedStyle property of the defaultView object.)

Comment 20

17 years ago
I was wrong. :-(
It's only partly fixed: The offset* properties work correctly in NB2001012020,
but there are still problems with the W3C methods. I add yet another version of
the testcase where I only changed the order of the output so that the W3C
methods are called first. That way the bug shows up also with NB2001012020.

Comment 21

17 years ago
Created attachment 24688 [details]
the modified testcase
Keywords: dom2
Component: DOM Level 2 → DOM Style
Taking QA Contact on all open or unverified DOM Style bugs...
QA Contact: vidur → ian

Comment 23

17 years ago
the remainders of this bug have disappeared somewhen around M0.9. I think this
should now be marked fixed or worksforme.

Comment 24

17 years ago
2001070904/Win2k works fine.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.