FAQ 9.3--Replacement?

Discussion in 'Javascript' started by David Mark, Nov 26, 2009.

  1. David Mark

    David Mark Guest

    <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, Nov 26, 2009
    #1
    1. Advertising

  2. 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/
     
    Garrett Smith, Nov 26, 2009
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    On Nov 26, 2:44 am, Garrett Smith <> 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). ;)
     
    David Mark, Nov 27, 2009
    #3
  4. David Mark

    David Mark Guest

    On Nov 26, 1:03 am, David Mark <> 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).
     
    David Mark, Nov 27, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Youhanna Mounir
    Replies:
    3
    Views:
    560
  2. =?ISO-8859-15?Q?Juli=E1n?= Albo

    FAQ or not FAQ?

    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jan 8, 2007, in forum: C++
    Replies:
    28
    Views:
    887
    Grizlyk
    Jan 15, 2007
  3. Josef 'Jupp' Schugt
    Replies:
    0
    Views:
    222
    Josef 'Jupp' Schugt
    Sep 22, 2003
  4. FAQ server

    FAQ - How do I direct someone to this FAQ?

    FAQ server, Aug 4, 2006, in forum: Javascript
    Replies:
    1
    Views:
    174
    Dr John Stockton
    Aug 4, 2006
  5. Peter Michaux

    FAQ/FAQ notes site makeover

    Peter Michaux, Nov 22, 2006, in forum: Javascript
    Replies:
    22
    Views:
    371
    Randy Webb
    Nov 27, 2006
Loading...

Share This Page