Closed Bug 44545 Opened 24 years ago Closed 23 years ago

document.body.offset* returns 0.

Categories

(Core :: DOM: CSS Object Model, defect, P3)

Product:
Core
Component:
DOM: CSS Object Model
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: sea, Assigned: jst)

References

Details

(Keywords: dom2)

Attachments

(3 files)

test case for all the bugs
1.34 KB, text/html
Details
testcase as above, but now with the "workaround"
1.40 KB, text/html
Details
the modified testcase
1.34 KB, text/html
Details 
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>
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
Closed: 24 years ago
Resolution: --- → INVALID
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. 
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 → ---
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.
Going to go ahead and mark as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
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.
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
*** Bug 48956 has been marked as a duplicate of this bug. ***
*** Bug 48956 has been marked as a duplicate of this bug. ***
Adding woschwarz@gmx.de to cc list
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.

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) :).

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).
 
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.


Could someone attach some testcases here please?
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 ??
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.)

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.
Attached file 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

    
    

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

    
    

    
  
2001070904/Win2k works fine.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: