Closed Bug 156388 Opened 22 years ago Closed 21 years ago

Implement document.documentElement.clientWidth and document.documentElement.clientHeight


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: bugzilla, Unassigned)



(Keywords: testcase)


(2 files)

This bug is the cousin of bug 62536. The purpose here is to implement
document.documentElement.clientWidth/clientHeight DHTML properties within Moz
exactly the way it works within MSIE 6 in standards compliant mode. Solving this
bug, I feel, would eliminate all the problems and frustations related to precise
and accurate layout of web sites where knowing exactly the dimensions of the
client area (also known, referred as content area) and the dimensions of the
browser viewport are decisive.

I believe bug 140308 and bug 48634 as re-summarized (and maybe bug 72540, bug
76197) to be very much related to the implementation of
document.documentElement.clientHeight/Width. People in bug 140308 and bug 48634
want the window.innerWidth and window.innerHeight properties to "behave" like
MSIE's document.documentElement.clientWidth/Height properties.

Right now, the latest nightly build of Mozilla returns 0 for these properties.

A test case follows.
** You must use MSIE 6 in order to view this test case **
There is no other way to illustrate how MSIE 6 renders these properties in
"CSS1Compat" mode.
Using a high video screen resolution is better, preferable.
The moving lines (red, blue, purple ones) purpose is to illustrate how
absolutely positioned elements when positioned outside the client area cause
the root element to be streched, cause the dimensions of the root elements to
be increased and cause the appearance of scrollbars. (Another specific test
case might be needed to better achieve this.) Absolutely positioned elements
are taken out of normal flow and are positioned outside the body element in the
html element.
One final note: MSIE 6 does not render margins for the html element, does not
display margins for the html element but Mozilla-based browsers do.
Additional comments on the test case.
Move the mouse to the far right, beyond the lime border and/or move the mouse to
the bottom beyond the lime border. This will create scrollbars and the values of
document.documentElement.clientWidth/Height will be updated in real time. This
is the behavior that many people "expect" or demand (bug 140308, bug 48634) from
window.innerHeight/Width properties. Window.innerHeight/Width are totally
different properties measuring something else. 
To the right component.
Assignee: joki → jst
Component: DOM Events → DOM Mozilla Extensions
QA Contact: vladimire → lchiang
Blocks: 125419
Ever confirmed: true
QA Contact: lchiang → ian
That this does not work really amazes me. Why is it that clientWidth works for
any element but the root element? Is it possible that the root element has a
different type of ScrollView than other scrollable elements? Most likely yes,
and since clientWidth uses the scrollView.clipView.bounds something is going
wrong here.

(Sorry I could not get that deep into the code to actually find the problem but
I think I at least got a bit closer to finding the reason for the bug.)
No longer blocks: 125419
"Is it possible that the root element has a
different type of ScrollView"

It is possible that I don't know what this means, but I'll make a stab in the
dark. HTML{ overflow: auto; } causes scrollbars to disappear. Does this mean

If you try it with javascript on a loaded document, scrollbars remain but disappear.

Try it:

Is there a dependency? I think this may be related to bug 54661
Re comment #4 and #5:
Try the following page with MSIE 6 for windows, Mozilla, etc... and you'll see
differences (but these values are constant for each browser and each rendering
mode) in the margins applied to the body, to the overflow (and overflow-y)
values of both the body and html elements, even a default border on the html
element for MSIE 6, etc.etc. I just added css width and css height a few min. ago.

Also, please try the attachment 90581 [details] in this bugfile if you have MSIE 6 for
windows: I think it is revealing, empirically demonstrating some of the hidden
default browser values of the html and body elements.
clientHeight Property
Internet Development Index

Retrieves the height of the object including padding, but not including margin,
border, or scroll bar. 

documentElement.clientHeight may be higher than window.innerHeight. 
documentElement.clientHeight may be lower than window.innerHeight. 

1) documentElement.clientHeight will be higher than window.innerHeight when the
html element has height: auto. What you really want is the offsetHeight of the
ICB, which is really window.innerHeight - vScrollbarWidth. 

2) documentElement.clientHeight will be lower than window.innerHeight when the
html element has borders.

3) documentElement.clientHeight will be lower than window.innerHeight when the
html element has a height property that is less than the window's innerHeight.

In statement 1, the initial containing block has the scrollbar. the height of
the html element is unchanged. it may be higher than the ICB containing it. The
ICB has a default scrolling mechanism that is provided automatically by the browser.

In statement 2, borders are not included in the clientHeight property. If the
offsetHeight of the root (html) has borders, it's clientHeight must be less than
the innerWidth.

In statement 3, If the offsetHeight of the root (html) is less than the height
of the viewport, then the clientHeight property will be less than
window.innerWidth. There currently is a bug in mozilla, bug 15405, that prevents
html from being less than the viewport's height, so statement 3 can't be tested
until that bug is first fixed (dependancy).
Mass-reassigning bugs to
Assignee: jst → dom_bugs
Attached file Testcase #2
From the Description above:
>The purpose here is to implement
>document.documentElement.clientWidth/clientHeight DHTML properties within Moz
>exactly the way it works within MSIE 6 in standards compliant mode.

I'm afraid that is an impossible goal, see bug 227567 comment 8 and 5.

With the patch in bug 227567, in "Testcase #2", I get diff: 10,10,15,25,25 
which is very close to what I get in IE: 10,10,16,26,26 (the IE scrollbar seems
to be 1px wider).

I think the patch in bug 227567 fixes the problems in this bug (it is very
close to what IE does)  -  or is there something I missed?
Depends on: 227567
Keywords: testcase
OS: Windows XP → All
In the testcase #2, I assume that these are divs all bordered with a 5px solid
border. But still, this bug is about the root (documentElement) element. I
created a simple testpage where the <body> node is entirely empty and I was
still able to get MSIE 6 to output the client area (or rendered area) dimensions
(clientWidth and clientHeight). I fail to see the problem. I have many testcase
pages; if I understood exactly what is the situation, I might be able to help.

You note a 1px difference in the scrollbars. FWIW, one can modify the
width/height of the vertical/horizontal scrollbar in XP for browsers like MSIE 6
and Opera 7 with
Start/Settings/Control Panel/Display/Appearance tab/Advanced button/Item:Scrollbar
and such measurements may vary from Windows theme to theme also.
FWIW, MSIE 6 has a default CSS border declaration on the <html> node which is 
medium #000000 inset
which explains the difference between clientHeight and offsetHeight... which
might be mysterious. 

I understand that the root element is directly associated with the browser
viewport in MSIE 6 when this is not the case (nor the default) in Mozilla.

In any case, Mats, as soon as the fix to bug 227567 is in the trunk, I'll be
happy to run tests for this bug. From the values you get with testcase #2, I
have a hunch that your patch should solve the issues with this bug.
Please file new bugs for any remaining problems (*one issue* per bug report),
including a minimized testcase, thanks.

-> FIXED (by bug 227567)
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 189112 has been marked as a duplicate of this bug. ***
Followings code works for me in IE6, FF3.5.3, Chrome5.0.375.127, and I think it summarizes the issues well. Felt it was important to post here, since similar new and reopened bugs are marked duplicates of this resolved bug.

   function docElem( property )
      var t
      return ((t = document.documentElement) || (t = document.body.parentNode)) && Util.isNumber( t[property] ) ? t : document.body
   // View width and height excluding any visible scrollbars
   //    1) document.client[Width|Height] always reliable when available, including Safari2
   //    2) document.documentElement.client[Width|Height] reliable in standards mode DOCTYPE, except for Safari2, Opera<9.5
   //    3) document.body.client[Width|Height] is gives correct result when #2 does not, except for Safari2
   //    4) When document.documentElement.client[Width|Height] is unreliable, it will be size of <html> element either greater or less than desired view size
   //    5) When document.body.client[Width|Height] is unreliable, it will be size of <body> element less than desired view size
   function viewSize()
      // This algorithm avoids creating test page to determine if document.documentElement.client[Width|Height] is greater then view size,
      // will succeed where such test page wouldn't detect dynamic unreliability,
      // and will only fail in the case the right or bottom edge is within the width of a scrollbar from edge of the viewport that has visible scrollbar(s).
      var doc = DocElem( 'clientWidth' ),
         body = document.body,
         w, h
      return Util.isNumber( document.clientWidth ) ? { w : document.clientWidth, h : document.clientHeight } :
         doc === body
         || (w = Math.max( doc.clientWidth, body.clientWidth )) > self.innerWidth
         || (h = Math.max( doc.clientHeight, body.clientHeight )) > self.innerHeight ? { w : body.clientWidth, h : body.clientHeight } :
         { w : w, h : h }
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.