Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #8116 > unrolled thread

FAQ Topic - How do I find the size of the window? (2011-11-08)

Back to article view | Back to comp.lang.javascript

Contents

  FAQ Topic - How do I find the size of the window? (2011-11-08) "FAQ server" <javascript@dotinternet.be> - 2011-11-08 00:00 +0000
    Re: FAQ Topic - How do I find the size of the window? (2011-11-08) David Mark <dmark.cinsoft@gmail.com> - 2011-11-08 06:10 -0800
      Re: FAQ Topic - How do I find the size of the window? (2011-11-08) Dr J R Stockton <reply1145@merlyn.demon.co.uk> - 2011-11-09 17:40 +0000
        Re: FAQ Topic - How do I find the size of the window? (2011-11-08) "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-11-10 09:22 +0200
        Re: FAQ Topic - How do I find the size of the window? (2011-11-08) David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 06:13 -0800

#8116 — FAQ Topic - How do I find the size of the window? (2011-11-08)

-----------------------------------------------------------------------
FAQ Topic - How do I find the size of the window?
-----------------------------------------------------------------------

Here is a detailed explanation of a cross-browser strategy to
find the dimensions of the viewport, excepting all chrome
(excludes scrollbars, etc).

We can consider various properties:

window.innerWidth
document.clientWidth
document.documentElement.clientWidth
document.body.clientWidth

Of the browsers that have an `innerWidth` property, most
include scrollbar dimensions. Some versions of KHTML browsers
(including Safari 2) do _not_ include scrollbar width.

The `window.inner*` properties are unreliable and not
useful here. We don't want scrollbar dimensions included.

document.clientWidth

Certain versions of KHTML, including Safari 2, have
`document.clientHeight` and `document.clientWidth`
properties. Where supported, these rare properties accurately
return the height and width of the viewport, without including
scrollbar dimensions.

document.documentElement.clientWidth
document.body.clientWidth

MSHTML (Trident), Firefox (Gecko), Opera (Presto), and Safari
(Webkit) all support `clientHeight` on `document.body`
and `document.documentElement`. The difficulty is figuring out
which one is reliable. In other words which object to get the
`clientHeight` property from:`documentElement` or `body`?

What the number returned from either of these properties
represents depends on the environment. The environment includes
the browser, its version, and the rendering mode of the document.
In quirks mode, we'll mostly want to use `body.clientHeight`
(except for in Safari 2).

document.body.clientHeight

Some environments will return the viewport height. Others will
return `0`. Yet others will return the `clientHeight` of
the `BODY` element.

document.documentElement.clientHeight

This is the more "standard" property for getting the height of
the viewport. It usually "works" in modern browsers in
standards mode. Notable exceptions include Safari 2 and
Opera  <= 9.25, both of which return the `clientHeight`
of the `html` _element_. (Oddly, Opera <= 9.25
in standards mode returns the width of the viewport for
`documentElement.clientWidth`).

With the exception of Safari 2, `body.clientHeight` is reliable
where `documentElement.clientHeight` is found to be unreliable.
For example, in Safari 3+, Opera, and Mozilla, all in quirks mode,
`document.documentElement.clientHeight` returns the `clientHeight`
of the `html` element (this may seem unsurprising but
it is not what we want).

Conversely, `document.body.clientHeight` will return
the height of the viewport in most cases where
`document.documentElement.clientHeight` does not. An exception
to that is Safari 2, where `documentElement.clientHeight`
and `body.clientHeight` both return the height of their
corresponding element (not what we want).

By using a combination of Feature Testing and Capability Testing,
the dimensions of the viewport can be strategically retrieved
from  the property that works in the environment the script is
running in. The trick is determining which property will give us
the value we want.

Since `document.clientHeight` is reliable where
(rarely) supported, and since browsers that support this property
don't return the viewport dimensions from
`document.body.clientHeight` or
`document.documentElement.clientHeight`, this should be the
very first condition:

// Safari 2 uses document.clientWidth (default).
if(typeof document.clientWidth == "number") {
// use document.clientWidth.
}

The next strategy is to determine if
`document.documentElement.clientHeight` property is unreliable.
It is deemed "unreliable" when it is either `0` or taller
than the viewport.

 Determining if `documentElement.clientHeight` is `0` is easy.
 The result is stored in a variable `IS_BODY_ACTING_ROOT`.

var docEl = document.documentElement,
IS_BODY_ACTING_ROOT = docEl && docEl.clientHeight === 0;
docEl = null;

To determine if `documentElement.clientHeight` returns
a value taller than the viewport, we need a Capability Test.

If we can force `documentElement` to be very tall
(taller than a normal viewport) we can then check to see if
`documentElement.clientHeight` returns that "very tall" number.
If it does, then it is unreliable.

We can force `documentElement` to be taller than the viewport
(or any "normal" viewport) by adding a `div` to the `body`,
give that `div` a height larger than any normal monitor,
and then check to see if `documentElement.clientHeight` is
that high (or "almost" that high, to account for `documentElement`
having a border).

// Used to feature test Opera returning wrong values
// for documentElement.clientHeight.
// The results of this function should be cached,
// so it does not need to be called more than once.
function isDocumentElementHeightOff(){
var d = document,
    div = d.createElement('div');
div.style.height = "2500px";
d.body.insertBefore(div, d.body.firstChild);
var r = d.documentElement.clientHeight > 2400;
d.body.removeChild(div);
return r;
}

We can use this function to see if we should use
`body.clientHeight`, instead. (but only after checking if
`document.clientHeight` is supported).

// Safari 2 uses document.clientWidth (default).
if(typeof document.clientWidth == "number") {
// use document.clientHeight/Width.
}
else if(IS_BODY_ACTING_ROOT || isDocumentElementHeightOff()) {
// use document.body.clientHeight/Width.
} else {
// use document.documentElement.clientHeight/Width.
}

The preceding strategy was developed by Garrett Smith with input
from John David Dalton. A complete and tested example can be found
in APE Library under `APE.dom.getViewportDimensions`.
Source code:
<URL: http://dhtmlkitchen.com/ape/build/dom/viewport-f.js>.
APE is publicly released under Academic Free License.
APE home: <URL: http://dhtmlkitchen.com/ape/>.

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

<URL: http://msdn.microsoft.com/en-us/library/ms533566%28VS.85%29.aspx>
<URL: http://developer.mozilla.org/en/DOM/window.innerWidth>
<URL: http://dev.opera.com/articles/view/using-capability-detection/>


The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/

-- 

The sendings of these daily posts are proficiently hosted
by http://www.pair.com.

[toc] | [next] | [standalone]

#8131

On Nov 7, 7:00 pm, "FAQ server" <javascr...@dotinternet.be> wrote:
> -----------------------------------------------------------------------
> FAQ Topic - How do I find the size of the window?
> -----------------------------------------------------------------------
>
> Here is a detailed explanation of a cross-browser strategy to
> find the dimensions of the viewport, excepting all chrome
> (excludes scrollbars, etc).
>
> We can consider various properties:
>
> window.innerWidth
> document.clientWidth
> document.documentElement.clientWidth
> document.body.clientWidth
>
> Of the browsers that have an `innerWidth` property, most
> include scrollbar dimensions. Some versions of KHTML browsers
> (including Safari 2) do _not_ include scrollbar width.
>
> The `window.inner*` properties are unreliable and not
> useful here. We don't want scrollbar dimensions included.
>
> document.clientWidth
>
> Certain versions of KHTML, including Safari 2, have
> `document.clientHeight` and `document.clientWidth`
> properties. Where supported, these rare properties accurately
> return the height and width of the viewport, without including
> scrollbar dimensions.
>
> document.documentElement.clientWidth
> document.body.clientWidth
>
> MSHTML (Trident), Firefox (Gecko), Opera (Presto), and Safari
> (Webkit) all support `clientHeight` on `document.body`
> and `document.documentElement`. The difficulty is figuring out
> which one is reliable. In other words which object to get the
> `clientHeight` property from:`documentElement` or `body`?
>
> What the number returned from either of these properties
> represents depends on the environment. The environment includes
> the browser, its version, and the rendering mode of the document.
> In quirks mode, we'll mostly want to use `body.clientHeight`
> (except for in Safari 2).
>
> document.body.clientHeight
>
> Some environments will return the viewport height. Others will
> return `0`. Yet others will return the `clientHeight` of
> the `BODY` element.
>
> document.documentElement.clientHeight
>
> This is the more "standard" property for getting the height of
> the viewport. It usually "works" in modern browsers in
> standards mode. Notable exceptions include Safari 2 and
> Opera  <= 9.25, both of which return the `clientHeight`
> of the `html` _element_. (Oddly, Opera <= 9.25
> in standards mode returns the width of the viewport for
> `documentElement.clientWidth`).
>
> With the exception of Safari 2, `body.clientHeight` is reliable
> where `documentElement.clientHeight` is found to be unreliable.
> For example, in Safari 3+, Opera, and Mozilla, all in quirks mode,
> `document.documentElement.clientHeight` returns the `clientHeight`
> of the `html` element (this may seem unsurprising but
> it is not what we want).
>
> Conversely, `document.body.clientHeight` will return
> the height of the viewport in most cases where
> `document.documentElement.clientHeight` does not. An exception
> to that is Safari 2, where `documentElement.clientHeight`
> and `body.clientHeight` both return the height of their
> corresponding element (not what we want).
>
> By using a combination of Feature Testing and Capability Testing,
> the dimensions of the viewport can be strategically retrieved
> from  the property that works in the environment the script is
> running in. The trick is determining which property will give us
> the value we want.
>
> Since `document.clientHeight` is reliable where
> (rarely) supported, and since browsers that support this property
> don't return the viewport dimensions from
> `document.body.clientHeight` or
> `document.documentElement.clientHeight`, this should be the
> very first condition:
>
> // Safari 2 uses document.clientWidth (default).
> if(typeof document.clientWidth == "number") {
> // use document.clientWidth.
>
> }
>
> The next strategy is to determine if
> `document.documentElement.clientHeight` property is unreliable.
> It is deemed "unreliable" when it is either `0` or taller
> than the viewport.
>
>  Determining if `documentElement.clientHeight` is `0` is easy.
>  The result is stored in a variable `IS_BODY_ACTING_ROOT`.
>
> var docEl = document.documentElement,
> IS_BODY_ACTING_ROOT = docEl && docEl.clientHeight === 0;
> docEl = null;
>
> To determine if `documentElement.clientHeight` returns
> a value taller than the viewport, we need a Capability Test.
>
> If we can force `documentElement` to be very tall
> (taller than a normal viewport) we can then check to see if
> `documentElement.clientHeight` returns that "very tall" number.
> If it does, then it is unreliable.
>
> We can force `documentElement` to be taller than the viewport
> (or any "normal" viewport) by adding a `div` to the `body`,
> give that `div` a height larger than any normal monitor,
> and then check to see if `documentElement.clientHeight` is
> that high (or "almost" that high, to account for `documentElement`
> having a border).
>
> // Used to feature test Opera returning wrong values
> // for documentElement.clientHeight.
> // The results of this function should be cached,
> // so it does not need to be called more than once.
> function isDocumentElementHeightOff(){
> var d = document,
>     div = d.createElement('div');
> div.style.height = "2500px";
> d.body.insertBefore(div, d.body.firstChild);
> var r = d.documentElement.clientHeight > 2400;
> d.body.removeChild(div);
> return r;
>
> }
>
> We can use this function to see if we should use
> `body.clientHeight`, instead. (but only after checking if
> `document.clientHeight` is supported).
>
> // Safari 2 uses document.clientWidth (default).
> if(typeof document.clientWidth == "number") {
> // use document.clientHeight/Width.}
>
> else if(IS_BODY_ACTING_ROOT || isDocumentElementHeightOff()) {
> // use document.body.clientHeight/Width.} else {
>
> // use document.documentElement.clientHeight/Width.
>
> }
>
> The preceding strategy was developed by Garrett Smith with input
> from John David Dalton.

And clearly an homage to My Library. :)

> A complete and tested example can be found
> in APE Library under `APE.dom.getViewportDimensions`.
> Source code:
> <URL:http://dhtmlkitchen.com/ape/build/dom/viewport-f.js>.
> APE is publicly released under Academic Free License.
> APE home: <URL:http://dhtmlkitchen.com/ape/>.
>
> Note: The dimensions cannot be determined accurately until after
> the document has finished loading.
>

As noted previously (and repeatedly), this is a bad explanation and
not the best solution either. Why is it still in the FAQ?  Is there
still no maintainer?

Better off reading my Viewport primer. Not because it is mine, but
because it is a much better explanation and example. And if you can
dig up Richard Cornford's old rendition, you might have a better one
still. Certainly you won't get anywhere reading or emulating that FAQ
entry. I ought to know as it is basically a botched riff on My
Library's approach (which isn't as good as the one in the primer). I
objected when it was first posted (as did others). The subject had
been discussed to death by that time, but apparently the FAQ
maintainer wasn't following closely.

http://www.cinsoft.net/viewport.asp

And times have changed a bit since either of these articles were
published. There are additional sets of properties that have to be
considered to get at what some mobile devices considers the viewport.
Wouldn't be hard to extend the Viewport primer (or My Library) to
suit. The FAQ article really has nowhere to go as the feature testing
is just for one observed quirk. I observed it and "fixed" it in My
Library in much the same way. Then later I realized I missed one basic
cause-effect relationship and the code could be simplified quite a
bit. Hence the primer.

[toc] | [prev] | [next] | [standalone]

#8188

In comp.lang.javascript message <587e394e-3764-467d-89b3-5b4363895580@c7
g2000vbj.googlegroups.com>, Tue, 8 Nov 2011 06:10:16, David Mark
<dmark.cinsoft@gmail.com> posted:

>As noted previously (and repeatedly), this is a bad explanation and
>not the best solution either. Why is it still in the FAQ?  Is there
>still no maintainer?

The answer to that is in the FAQ.

While I'm here : can the effect of script '<element>.style.cursor =
"pointer" ;' be achieved in HTML, and how?  Element is a TD or TH.

-- 
 (c) John Stockton, nr London UK.  ?@merlyn.demon.co.uk  IE8 FF3 Op12 Sf5 Cr12
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.

[toc] | [prev] | [next] | [standalone]

#8189

11/9/2011 7:40 PM, Dr J R Stockton wrote:

> While I'm here : can the effect of script '<element>.style.cursor =
> "pointer" ;' be achieved in HTML, and how?  Element is a TD or TH.

This looks like a trick question, or a rhetorical question, or trolling 
- I'll take it as a trick question. Although the question has nothing to 
do with the current Subject, I'll leave it to you to change the Subject 
if you have an idea of what this really about.

The first and obvious answer is yes, with
<td style="cursor: pointer">
but I suspect that this won't qualify, since it - like the JavaScript 
code, too - really makes use of CSS as the essential tool.

The next answer is:

<td><td><a id=myid42 href=#myid42>Hello world</a></td>

There are of course many ways to refute this answer. The theoretical 
objection is that there is no guarantee that browsers do what they 
actually do with links. A more practical point is that the effect spans 
only the link, not the cell, and there can be a huge difference 
(depending on other cells in the same column, and styling) - and fixing 
this with CSS would cause the same objections as the first answer.

The solution has some side effects, too, but side effects were not 
forbidden in the question.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#8196

On Nov 9, 12:40 pm, Dr J R Stockton <reply1...@merlyn.demon.co.uk>
wrote:
> In comp.lang.javascript message <587e394e-3764-467d-89b3-5b4363895580@c7
> g2000vbj.googlegroups.com>, Tue, 8 Nov 2011 06:10:16, David Mark
> <dmark.cins...@gmail.com> posted:
>
> >As noted previously (and repeatedly), this is a bad explanation and
> >not the best solution either. Why is it still in the FAQ?  Is there
> >still no maintainer?
>
> The answer to that is in the FAQ.

Thanks, doc!  Helpful as always. :)  I'll assume the FAQ is still
rudderless.

>
> While I'm here : can the effect of script '<element>.style.cursor =
> "pointer" ;' be achieved in HTML, and how?  Element is a TD or TH.
>

Johnny, I am really surprised at you.  Start a new thread for this and
clarify what you are trying to do.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web