"The properties: document.body.clientHeight, document.body.clientWidth
return different values on IE7, IE8 and Firefox:
document.body.clientHeight : 704 document.body.clientWidth : 1148
document.body.clientHeight : 704 document.body.clientWidth : 1132
document.body.clientHeight : 620 document.body.clientWidth : 1152"
This is certainly to be expected and not a problem at all, though many
libraries include "CSS resets" to try to "normalize" such differences
(for no good reason).
Why would anybody care if these numbers vary from one browser to the
next? Are they writing scripts with expected heights and widths hard-
coded in their logic?
"Why does this discrepancy exits? Are there any equivalent properties
that are consistent across different browsers (IE8, IE7, FireFox)"
I don't understand the obsession with trying to get the exact same
numbers for every property. jQuery does all sorts of bizarre things
to try to effect such "normalization", usually to its detriment (i.e.
its height/width methods violate the GIGO principal, often making the
retrieved numbers useless).
For example, if I want to add five pixels to the height or width of an
element, I can easily do it with basic DOM methods/properties, but in
jQuery, sometimes (depending on the browser, rendering mode, styling,
etc.) you can't get there from here as it fiddles with the returned
The "answer" with the green check mark (I think that means it is the
one chosen by the questioner as the most appropriate) is:-
"This has to do with the browser's box model. Use something like
Of course, this has nothing at all to do with box models. And the
magic answer to every "problem" is to use a library. No small wonder
that jQuery is the knee-jerk (emphasis on jerk) recommendation.
"What is jQuery equivalent for clientWidth and clientHeight?"
Something that doesn't work reliably.
"jQuery $(document).height $(document).width also return variable
values on different browsers"
And quite possibly the *wrong* values, at least if you need to do
anything with them besides needlessly comparing them to the results in
"Paul A is right about why the discrepancy exists but the solution
offered by Ngm is wrong (in the sense of JQuery).
The equivalent of clientHeight and clientWidth in jquery (1.3) is
It's all reads like random words thrown together. And IIRC, this
"solution" attempts to compute the viewport dimensions (which have
nothing to do with the clientWidth/Height of the body, except in IE
"It may be caused by IE's box model bug. To fix this, you can use the
Box Model Hack."
Again with the box model. You don't need any "Box Model Hack" to do
anything and MS invented the properties in question. There's no "box
This is the second responder with a Stack Overflow "score" over 5000.
Is it any wonder that developers are so confused? That site is a
blithering amplifier, churning out random nonsense sprinkled with
technical terms and exhortations to use jQuery.
"The equivalent of offsetHeight and offsetWidth in jQuery is $
(window).width(), $(window).height() It's not the clientHeight and
Even if that were true, why are developers so obsessed with finding
"equivalents" to perfectly usable properties.
"i had a similar problem - firefox returned the correct value of
obj.clientHeight but ie did not- it returned 0. I changed it to
obj.offsetHeight and it worked. Seems there is some state that ie has
for clientheight - that makes it iffy."
Insanity. And the worst thing is that the authors of jQuery (and the
rest of the "major" libraries) are also in the dark with these
properties. They may be able to recite what they mean, but they sure
don't know what to do with them. IIRC, jQuery's height/width methods
start with offsetHeight/Width and then try to compute and subtract the
border and padding, resulting in figures that are worthless for cross-
browser/DOM/box model compatibility. It's like they don't know what
problem they are trying to solve, except to try to make every number
come out the same to satisfy some dubious unit tests.
Odd considering these properties have behaved the same way since well
before the turn of the century. They are also fairly well-
documented. I believe the MSDN article that was posted with the
arrival of *IE4* is still up there (the one with the graphic that
illustrates which parts of the element are measured by each
property). Back in those days, we didn't have a jQuery to de-
normalize the DOM for us. :)
Like I've said before, it's not the browsers that are the problem.
It's the dubious and aimless libraries and the air of voodoo that
surrounds them that cause most of the problems.
This is a good example of why jQuery is popular and you are not.
jQuery offers a solution that makes people feel better. They get the
same number. They can work with that. In their opinion, they are
better off than where they started.
You offer no solution or explanation or help in any way. You post the
equivalent of "ha ha, look at these idiots who don't know the
Until you become helpful, you will continue to be seen as an
References for the sake of search:
Popular with whom? You? I honestly couldn't care less.
You come off like a petulant child (as usual).
> jQuery offers a solution that makes people feel better.
LOL. Kind of like snake oil?
> They get the
> same number. They can work with that. In their opinion, they are
> better off than where they started.
No, I suggest you read my post again.
> You offer no solution or explanation or help in any way.
Wrong. I've written extensively on the subject. Here is the
definitive treatment, which I guess you missed:-
> You post the
> equivalent of "ha ha, look at these idiots who don't know the
Again, I suggest you re-read my explanations.
> Until you become helpful, you will continue to be seen as an
> irrelevant side-show.
By you. The authors of these stupid things sure don't agree. And you
never take the time to thank for me that; instead choosing to pop up
like some deranged muppet every time I "insult" your favorite
library. Good luck with your popular but completely broken library.
You are doing your clients a great service with that thing.
And to alleviate any confusion among the uninitiated, there is no
"answer" to the "question" posted on StackOverflow and (as the name
indicates), that site is literally bursting with such exchanges (so I
can hardly correct them all). I have tried a few times in the past
and my real answers were voted down in favor or fantasy answers (the
type that recommend snake oil like jQuery to soothe the suffering of
incompetents, but do nothing but waste time and money for their
I'll make a wild prediction that the obsessive Matt Kruse made no
attempt to "answer" that exchange either.
And as for him, he's like that guy in Memento. Based on his postings
of the last three years, he apparently can't form new memories. I
think he carries around worn out polaroids of me and John Resig.
Under Resig's he's written "pretty good" and under mine "unhelpful".
Don't trust his lies. ;)
> And to alleviate any confusion among the uninitiated, there is no
> "answer" to the "question" posted on StackOverflow and (as the name
> indicates), that site is literally bursting with such exchanges (so I
> can hardly correct them all). I have tried a few times in the past
> and my real answers were voted down in favor or fantasy answers (the
> type that recommend snake oil like jQuery to soothe the suffering of
> incompetents, but do nothing but waste time and money for their
Have you ever noticed your postings are consistently shot down in every
format that has any sort of moderation?
You should ask yourself... "why is that?"
> You should ask yourself... "why is that?"
No I shouldn't as it isn't true.
Have you ever noticed that you have nothing useful to say?
The subject of this thread (Now I've seen everything) seems a little
over the top attached to a case of an individual who doesn't know any
better failing to ask the right question and getting a series of
different 'try this' response form people to whom stopping and finding
out what actual problem they are proposing 'solutions' for is
unimaginable. That is not unexpected, it is pretty much the norm for
Generally the level of understanding/knowledge in web development is
so low that each new exhibit in the parade of jaw-dropping stupidity
actually does little more than raise an eyebrow. For example,
yesterday, while looking at a post-log-out HTML page on a client's
intranet I noticed this at the bottom of the page:-
| <!-- bonus HEAD section
| as per http://support.microsoft.com/kb/q222064/ -->
| <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
| <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="no-cache">
| <META HTTP-EQUIV="Expires" CONTENT="0">
A "bonus HEAD section" (and there was another one at the top of the
page) is such a ludicrous notion that it is hard (but not impossible,
given Microsoft's record on web development) to believe that it would
be recommend in a Microsoft knowledge base article, or that anyone
sane would take it seriously if it were.
For those not interested in reading the article the proposition is
that <META HTTP-EQUIV="CACHE-CONTROL" ... > will not be acted upon if
found prior to the page filling half of a 64KB 'buffer' because up
until that point there is nothing in the cache to act upon. Microsoft
propose that this be addressed by placing an additional HEAD section
at the bottom of the page and placing the offending META elements
within it. (They do not say what implications follow from the total
size of the page being less than half of their 64KB 'buffer', and so
any inserted HEAD section sill being encountered prior to the cache
entry being created).
The article does not suggest that there are any issues with real HTTP
headers, but also does not suggest them as an alternative approach to
their issue with META elements.
The page where I encountered this was sent with the headers:-
| HTTP/1.1 200 OK
| Server: Sun-ONE-Web-Server/6.1
| Date: Tue, 03 Aug 2010 12:41:26 GMT
| Content-length: 2142
| Content-type: text/html
| Last-modified: Mon, 23 Feb 2009 23:49:07 GMT
| Etag: "85e-49a335f3"
| Accept-ranges: bytes
- so clearly there is someone who is willing to do ridiculous things
to discourage IE from caching this page, but not willing or able to
set up the headers for the response such that they would discourage
caching. This client is a large (but unnameable, for the usual
reasons) US bank who have a large internal IT department that employs
the 'web developers' who created this and 'Websphere experts' to set
up the servers so you would expect better (it is not lack of funds
that prevent them from hiring people who understand what they are
This is a case of solving the wrong problem in the wrong way, but as
such it is no more tha just another case of doing that. I am fairly
confident that I never will have "seen everything".
Perhaps a typo for "bogus"... :p
Totally. I can't see reason for getting upset about someone who is
> The page where I encountered this was sent with the headers:-
Uh-oh. That might be cached. Better add an extra head.
(Kidding, of course).
> - so clearly there is someone who is willing to do ridiculous things
> to discourage IE from caching this page, but not willing or able to
> set up the headers for the response such that they would discourage
> caching. This client is a large (but unnameable, for the usual
> reasons) US bank who have a large internal IT department that employs
> the 'web developers' who created this and 'Websphere experts' to set
> up the servers so you would expect better (it is not lack of funds
> that prevent them from hiring people who understand what they are
US banks spend a lot of money on projects, mostly wasting it in process
and red tape. They usually pay on the low-end of market rate and provide
an environment that good developers find stifling.
As usual, you missed the point. Re-read my original post and see if
you can figure out who (or what) I was "upset" about.
Much of the IT related 'red tape' I encounter from financial services
clients is about verifying that systems actually do what they are
supposed to be doing, which seems like a good thing to be verifying
when you are handling other people's money.
> They usually pay on the low-end of market rate and provide
> an environment that good developers find stifling.
An unwillingness/inability to direct funds towards employing competent
developers is not the same as not having the funds to do so.