FAQ Topic - How do I find the size of the window/browser canvas area?

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - How do I find the size of the window/browser
canvas area?
-----------------------------------------------------------------------

While it is often asked about window size, what is more relevant is
the "canvas area" of the browser.

Where supported in NN: (>NN4.0)

var winWidth = window.innerWidth;
var winHeight = window.innerHeight;

Where supported in IE: (>IE4.0)

var winWidth = document.body.clientWidth;
var winHeight = document.body.clientHeight;

Where supported in modern browsers:

var winWidth = document.documentElement.clientWidth;
var winHeight = document.documentElement.clientHeight;

Where supported in DOM compliant browsers:

var winWidth, winHeight, d=document;
if (typeof window.innerWidth!='undefined') {
winWidth = window.innerWidth;
winHeight = window.innerHeight;
} else {
if (d.documentElement &&
typeof d.documentElement.clientWidth!='undefined' &&
d.documentElement.clientWidth!==0) {
winWidth = d.documentElement.clientWidth;
winHeight = d.documentElement.clientHeight;
} else {
if (d.body &&
typeof d.body.clientWidth!='undefined') {
winWidth = d.body.clientWidth;
winHeight = d.body.clientHeight;
}
}
}

Note: The dimensions can not be determined accurately until after the
document has finished loading.

http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/clientWidth.asp

http://docs.sun.com/source/816-6408-10/window.htm#1202446

http://msdn.microsoft.com/workshop/author/om/measuring.asp


--
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://jibbering.com/faq/index.html.
The FAQ workers are a group of volunteers. The sendings of these
daily posts are proficiently hosted by http://www.pair.com.

 

[David Mark]

-----------------------------------------------------------------------
FAQ Topic - How do I find the size of the window/browser
canvas area?
-----------------------------------------------------------------------

While it is often asked about window size, what is more relevant is
the "canvas area" of the browser.

Where supported in NN: (>NN4.0)

var winWidth = window.innerWidth;
var winHeight = window.innerHeight;

Includes scrollbar area (if present.)

Where supported in IE: (>IE4.0)

var winWidth = document.body.clientWidth;
var winHeight = document.body.clientHeight;

Only in quirks mode for IE6+.

Where supported in modern browsers:

var winWidth = document.documentElement.clientWidth;
var winHeight = document.documentElement.clientHeight;

Where supported in DOM compliant browsers:

var winWidth, winHeight, d=document;
if (typeof window.innerWidth!='undefined') {
winWidth = window.innerWidth;
winHeight = window.innerHeight;
} else {
if (d.documentElement &&
typeof d.documentElement.clientWidth!='undefined' &&
d.documentElement.clientWidth!==0) {
winWidth = d.documentElement.clientWidth;
winHeight = d.documentElement.clientHeight;

Fails in Opera 9, returning the height of the document for
clientHeight. Also, margins and/or borders on the HTML element will
throw these calculations off in some browsers (IE comes to mind.)

Though probably too convoluted for the FAQ, a "complete
solution" (quotes indicate it hasn't been tested in every browser on
every platform) can be found in this project:

http://code.google.com/p/niceshowcase/

See niceshowcase.js. The name of the function is viewportSize.

 

[David Mark]

David Mark said the following on 10/15/2007 7:51 PM:



Which is correct behavior since the scrollbars belong to the document

It is inconsistent with what clientWidth/Height returns. In practice
the area inside the scrollbars is what is useful (e.g. for centering
or maximizing elements.)

Wouldn't "Where supported" cover that?

I think it would be clearer to mention when it is supported.

Egads. window.innerHeight seems to give me the right number in Opera9 in
limited testing.

But since innerHeight returns the scrollbar area, you typically want
to try clientWidth/Height first.

If you set the width of the html element to 200px, what is the width of
the canvas you have to work with? IE and Firefox give me 180px (which
allows the 20px for the scrollbars). Opera still gives me the viewport
dimensions. Strange stuff indeed.

That illustrates the inconsistency of innerWidth/Height, even in
modern browsers. Assuming one has a use for the viewport dimensions
with scrollbars included, it would require lots of feature detection
and workarounds to get those results consistently. I am not sure how
much work it would be as I never wanted those results. For starters,
you would use offsetWidth/Height as opposed to clientWidth/Height.

I looked at it briefly and looked different from the FAQ code but not a

The biggest difference is that it relegates the use of innerWidth/
Height to browsers that do not support clientWidth/Height (e.g. NS6.)
The FAQ version tries those first.

lot of difference. It does comment that the function still gets O9 wrong
in some circumstances.

In Opera 9, if the height of the HTML element is less than the height
of the viewport (no vertical scrollbar), it returns the height of the
HTML element. As soon as a measurement is taken with a vertical
scrollbar present, the clientHeight quirk is detected and future
measurements will return the viewport height (minus the horizontal
scrollbar if present), whether a vertical scrollbar is present or
not. Come to think of it, I could set a cookie and make that flag
persist for the duration of the session.

If not for that one Opera quirk, the code would be considerably
simpler and slightly smaller. I think there would be a lot more
quirks to deal with if trying to reliably include the scrollbar areas
in the measurements. I can't think of any use for that data, so I
won't bother trying to come up with a solution.

 

[David Mark]

David Mark said the following on 10/17/2007 12:30 AM:







That is true.



OK.



I am leaving in the next 24/48 hours going out of town for about 2
weeks. If nobody does it before then, I will look at the version you
linked to and see about getting the FAQ updated. If anybody else does

Let me know what part(s) of it would be appropriate for the FAQ and
I'll put it together. The Opera 9 workaround seems like it would be
too much for a simple example. Perhaps a notation about the Opera 9
bug would suffice. Similarly, my code has extra baggage to deal with
odd CSS configurations (like margins and borders on the HTML element),
which are worked out with the help of lower-level functions, which in
turn use a getComputedStyle wrapper, etc. All told, it is probably
too much for a FAQ entry.

it, I would prefer it be a function rather than just simple code. I also
want it to pass through JSLint without error (meaning, no new Function
construction).

I can't imagine why the Function constructor would be used, but the
all of the code in the cited project passes JSLint.

 

[David Mark]

David Mark said the following on 10/17/2007 3:19 AM:



I think that a simple "works in modern browser" answer is all that needs
to be in the FAQ itself and then leave a long drawn out "all
encompassing" version for a Notes page. As for the code itself, I would
want a conditional function where the body of the function is created
depending on what the browser supports (much the way DynWrite is
written) so that it only checks once for what the browser supports and
then creates the function based on that instead of checking every time
the function is executed.

That's what mine does.

I'll get a trimmed down version ready for the FAQ.

 

[Richard Cornford]

Maximising/clipping perhaps, but I would not have thought that centring
was an activity where worrying about being off by half the width of the
scrollbars was worthwhile.


The advantage of innerWidth/Height is that they are virtually
universally supported and very consistently. If you use those in
preference then the only real remaining problem is IE and for IE it is
possible to know which object to read the client region dimensions from
in which mode.

The innerWidth/Height may not be the ideal values to know but they are
at least often the correct values (when there are no scrollbars) and
they are never out by much.

Let me know what part(s) of it would be appropriate for the FAQ
and I'll put it together. The Opera 9 workaround seems like it
would be too much for a simple example.

That could be a very serious problem. The code as it is may not be ideal
but it is never that wrong either. If you try to use clientWidth/Height
in preference and do not take account of the browsers like Opera where
you may be accidentally reading the document dimensions then the
resulting code could produce very wrong results on occasions.

Perhaps a notation about the Opera 9 bug would suffice.

And leave people to program the complicated bit for themselves?

Similarly, my code has extra baggage to deal with
odd CSS configurations (like margins and borders on the HTML
element),

Any context where an HTML element has margins, padding or borders should
be disregarded. And anyone writing CSS to include those sacked.

which are worked out with the help of lower-level functions,
which in turn use a getComputedStyle wrapper, etc. All told,
it is probably too much for a FAQ entry.

<snip>

This is not the first time this entry has been subject to this
criticism. As I still see it the main problem with changing it is the
size of the result. My own version of an alternative came out at over
200 lines without comments, and considerably more if commented/explained
to the point where a reader could be expected to understand what the
code was doing:-

<URL:
http://groups.google.com/group/comp..._frm/thread/f978c2d6f014d711/882bde3b875a6ccb >

What we do have is a facility for adding longer/complete examples as
notes for the FAQ.

Richard.

 

[David Mark]

Maximising/clipping perhaps, but I would not have thought that centring
was an activity where worrying about being off by half the width of the
scrollbars was worthwhile.

I somewhat agree, but it depends on the ratio of the scrollbars'
dimensions to the canvas area. And certainly centering is the least
worrisome in this regard.

The advantage of innerWidth/Height is that they are virtually
universally supported and very consistently. If you use those in

But sometimes it includes scrollbars and sometimes it doesn't. Older
Opera browsers come to mind. NS4 too according to this:

http://www.jibbering.com/2002/7/drunclear-measure.html

preference then the only real remaining problem is IE and for IE it is
possible to know which object to read the client region dimensions from
in which mode.

But the problem is that client region dimensions don't include the
scrollbars, so you are getting one thing for IE and something else for
others. If the FAQ entry is to stick with the dimensions including
scrollbars, then it should use offsetWidth/Height for IE.

The innerWidth/Height may not be the ideal values to know but they are
at least often the correct values (when there are no scrollbars) and
they are never out by much.

Depends on how big the scrollbars in relation to the size of the
canvas. Granted it is usually an insignificant number of pixels. But
if you are maximizing an element, one pixel too many will introduce
unneeded scrollbars.

That could be a very serious problem. The code as it is may not be ideal
but it is never that wrong either. If you try to use clientWidth/Height
in preference and do not take account of the browsers like Opera where
you may be accidentally reading the document dimensions then the
resulting code could produce very wrong results on occasions.

Right. But the only wrong result mine can produce is to use document
dimensions which are smaller than the viewport, which is less than
catastrophic. I decided that was better than falling back to
innerHeight before the scrollbar thickness was known. Once the
scrollbar thickness is known, the code falls back to innerHeight and
corrects for the horizontal scrollbar (if present.) Of couse, if I
remove the Opera workaround logic for an abbreviated FAQ version, the
possibility of returning a document height that is greater than the
viewport would exist and that would be a serious problem.

And leave people to program the complicated bit for themselves?

That's a good point.

Any context where an HTML element has margins, padding or borders should
be disregarded. And anyone writing CSS to include those sacked.

I agree with the second part. Of course, the example cited above uses
HTML borders.

<snip>

This is not the first time this entry has been subject to this
criticism. As I still see it the main problem with changing it is the
size of the result. My own version of an alternative came out at over
200 lines without comments, and considerably more if commented/explained
to the point where a reader could be expected to understand what the
code was doing:-

<URL:http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...>

From looking at your code, I figured out an additional test which will

perfect my Opera 9 (and previous versions apparently) workaround. I
was unable to determine if documentElement.clientHeight was bogus
(equivalent to scrollHeight) until there was a vertical scrollbar
present. It turns out that I should have checked the clientHeight of
the body element. The Opera developers are out of their minds
apparently as documentElement.clientHeight should never report the
scroll height of the document and if it does then body.clientHeight
should report the scroll height of the body portion of the document
(not the viewport client height.) The strangest thing that I noticed
when I tested my version is that documentElement.clientWidth works as
expected in Opera. How they could botch the height, but not the
width, is beyond me.

If I go back and add modify the Opera workaround to check the
clientHeight of the body, I might as well keep the code that deals
with HTML borders and margins as these are far more common on the BODY
element. Some brief testing with Opera 9 shows that they must be
accounted for in identical fashion.

I also noticed that you attempt to deal with the possibility of
differences in thickness of horizontal and vertical scrollbars. I
can't imagine an OS that would have such a quirk, so I decided not to
bother with the added complexity.

What we do have is a facility for adding longer/complete examples as
notes for the FAQ.

Right. I am sure that is where any version that attempts to exlude
scrollbars should end up. As for a shorter version, it would almost
certainly have to include scrollbars. Switching to offsetHeight/Width
for browsers that don't support innerHeight/Width should be done for
the sake of consistency.