«

<FAQENTRY>

I think we've been over the various shortcomings of this:-

http://www.jibbering.com/faq/#getWindowSize

For one, it doesn't mention document.compatMode and it infers too much
from document.documentElement.clientHeight === 0 (width is a better
choice too). The feature test is aimed at one observed anomaly,
rather than trying to figure out which element represents the viewport
(i.e. has the scroll bars).

I recently pared down the version from My Library. Didn't lose
anything except support for margins on the HTML element (which would
obviously be an insane design). I have put a simplified test page and
explanations here:-

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

I'm not saying it is perfect, but it is certainly a more robust design
than the current rendition. I am open to suggestions on the order of
tests and inferences made. Also, I'm sure some of the explanations
could be more clear.

Tested with IE7/8, Opera 8.54/9.27, Chrome, Windows Safari 4, FF 3.5
in all modes (with and without body borders),

I do note that IE8 has an unrelated bug (dealt with in the test page)
that causes an element at left 0,with an offsetWidth equal to the
documentElement (or body in quirks mode) clientWidth to create a 1px
horizontal overflow in some cases (have yet to pin down which cases).
Compatibility mode too and I am 100% sure that IE7 never behaved this
way. Very odd, but the fix is trivial.

Or, depending on the results of these tests and discussions, we could
revert back to the old article.

David Mark wrote:
> <FAQENTRY>
>
> I think we've been over the various shortcomings of this:-
>
> http://www.jibbering.com/faq/#getWindowSize
>
> For one, it doesn't mention document.compatMode

Document.compatMode is not as closely related to the problem. I seem to
recall there was a browser where document.compatMode test failed. It may
have been mac IE.

and it infers too much
> from document.documentElement.clientHeight === 0 (width is a better
> choice too).
Why?

The feature test is aimed at one observed anomaly,
> rather than trying to figure out which element represents the viewport
> (i.e. has the scroll bars).
>
The goal is to use the "de facto" standard of
"documentElement.clientWidth".

document.body.clientWidth is a sort of "deprecated" or "quirks" de facto
standard. It fails on a lot of older versions of Firefox where it would
duly return the clientWidth of the body *element*. So that is the why
the code checks documentElement first.

The FAQ function can remove support for Opera < 9.5, and so the method:
isDocumentElementHeightOff

can be removed, with the explanation.

> I recently pared down the version from My Library. Didn't lose
> anything except support for margins on the HTML element (which would
> obviously be an insane design). I have put a simplified test page and
> explanations here:-
>
> http://www.cinsoft.net/viewport.asp
>
> I'm not saying it is perfect, but it is certainly a more robust design
> than the current rendition. I am open to suggestions on the order of
> tests and inferences made. Also, I'm sure some of the explanations
> could be more clear.
>
I'll try taking a closer look at it next week. I suggest you use spaces
when publishing code in a PRE.

> Tested with IE7/8, Opera 8.54/9.27, Chrome, Windows Safari 4, FF 3.5
> in all modes (with and without body borders),
>

AISI, the time spent making something work in quirks mode could be
better used in fixing the page to use standards mode.

> I do note that IE8 has an unrelated bug (dealt with in the test page)
> that causes an element at left 0,with an offsetWidth equal to the
> documentElement (or body in quirks mode) clientWidth to create a 1px
> horizontal overflow in some cases (have yet to pin down which cases).
> Compatibility mode too and I am 100% sure that IE7 never behaved this
> way. Very odd, but the fix is trivial.
>
That is odd. I guess you could just give a negative margin right, but
why does it matter?

> Or, depending on the results of these tests and discussions, we could
> revert back to the old article.

Which old article? The existing FAQ?

I think changing that FAQ entry is a good idea. I'd like it to be
shorter. Removing the explanation of Opera < 9.5 would reduce the length
a lot.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Nov 26, 2:44*am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> David Mark wrote:
> > <FAQENTRY>
>
> > I think we've been over the various shortcomings of this:-
>
> >http://www.jibbering.com/faq/#getWindowSize
>
> > For one, it doesn't mention document.compatMode
>
> Document.compatMode is not as closely related to the problem. I seem to
> recall there was a browser where document.compatMode test failed. It may
> have been mac IE.

Depends on what you mean by failed. Neither Safari 2 nor IE < 6 have
this property. The older Operas do have it, but it does indicate the
object that reports the correct properties. That's why that test has
seemingly become superfluous in my code. The new feature test works
without it.

I added scroll position reporting last night without any additional
checks (e.g. watching for changes in the properties) and, as expected,
worked in all browsers tested.

>
> and it infers too much> from document.documentElement.clientHeight === 0 (width is a better
> > choice too). *
>
> Why?

Because a 0 height may just mean an empty document (or the browser is
sized so the viewport has no height. A 0 width is a definite red flag
(hard to make that happen by sizing the browser window).

>
> The feature test is aimed at one observed anomaly,> rather than trying tofigure out which element represents the viewport
> > (i.e. has the scroll bars).
>
> The goal is to use the "de facto" standard of
> "documentElement.clientWidth".

The goal is to measure the client area of the viewport. I don't see
how documentElement.clientWidth is any sort of standard for that. Not
even in IE.

>
> document.body.clientWidth is a sort of "deprecated" or "quirks" de facto
> standard.

No. That's where you went off the path. The
document.body.clientWidth property is used when the body is the
viewport, which makes _perfect_ sense. As mentioned in the
explanations, the other browsers missed this "subtlety" as well when
they tried to copy the MS implementation.

> It fails on a lot of older versions of Firefox where it would
> duly return the clientWidth of the body *element*. So that is the why
> the code checks documentElement first.

What fails in a lot of older versions of FF?

>
> The FAQ function can remove support for Opera < 9.5, and so the method:
> isDocumentElementHeightOff
>
> can be removed, with the explanation.

You are still looking at this as a one browser issue. It's not
(perhaps that's why you were having troubles with older FF versions?)

>
> > I recently pared down the version from My Library. *Didn't lose
> > anything except support for margins on the HTML element (which would
> > obviously be an insane design). *I have put a simplified test page and
> > explanations here:-
>
> >http://www.cinsoft.net/viewport.asp
>
> > I'm not saying it is perfect, but it is certainly a more robust design
> > than the current rendition. *I am open to suggestions on the order of
> > tests and inferences made. *Also, I'm sure some of the explanations
> > could be more clear.
>
> I'll try taking a closer look at it next week. I suggest you use spaces
> when publishing code in a PRE.

I know that. Unfortunately, the code uses tabs and I didn't have time
to re-format it. I will do that once I am ready to paste it back into
My Library.

>
> > Tested with IE7/8, Opera 8.54/9.27, Chrome, Windows Safari 4, FF 3.5
> > in all modes (with and without body borders),
>
> AISI, the time spent making something work in quirks mode could be
> better used in fixing the page to use standards mode.
>
> > I do note that IE8 has an unrelated bug (dealt with in the test page)
> > that causes an element at left 0,with an offsetWidth equal to the
> > documentElement (or body in quirks mode) clientWidth to create a 1px
> > horizontal overflow in some cases (have yet to pin down which cases).
> > Compatibility mode too and I am 100% sure that IE7 never behaved this
> > way. *Very odd, but the fix is trivial.
>
> That is odd. I guess you could just give a negative margin right, but
> why does it matter?

It's simply a bug in IE. No, I didn't use a margin to fix it (I
adjusted the width back one if the "viewport element" unexpectedly
overflowed.

>
> > Or, depending on the results of these tests and discussions, we could
> > revert back to the old article.
>
> Which old article? The existing FAQ?

No, the original article on this subject. But after my testing last
night, I'm confident I have a much more robust solution.

>
> I think changing that FAQ entry is a good idea. I'd like it to be
> shorter. Removing the explanation of Opera < 9.5 would reduce the length
> a lot.

Lets get the logic and explanations right and then decide what to
prune. You will notice that my solution is not targeting any specific
quirk. It's based on logic, not observations (unless you consider the
feature test to be observing on the fly).

On Nov 26, 1:03*am, David Mark <dmark.cins...@gmail.com> wrote:
> <FAQENTRY>
>

One correction on the test page. Wasn't putting back body borders
properly after a feature test. Didn't affect the outcome of the
tests, but was very ugly in IE (and possibly others).

Another possible simplification for the FAQ is to eliminate multi-
window support (something I am making a bit more robust in the version
slated for the library).