D
David Mark
http://stackoverflow.com/questions/...urning-different-values-on-different-browsers
"The properties: document.body.clientHeight, document.body.clientWidth
return different values on IE7, IE8 and Firefox:
IE 8:
document.body.clientHeight : 704 document.body.clientWidth : 1148
IE 7:
document.body.clientHeight : 704 document.body.clientWidth : 1132
FireFox:
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
dimensions.
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
jQuery or another JavaScript abstraction library to normalize the DOM
model."
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
other browsers.
"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
$(window).width(), $(window).height()"
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
quirks mode).
"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
model bug".
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
clientWidth"
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.
"The properties: document.body.clientHeight, document.body.clientWidth
return different values on IE7, IE8 and Firefox:
IE 8:
document.body.clientHeight : 704 document.body.clientWidth : 1148
IE 7:
document.body.clientHeight : 704 document.body.clientWidth : 1132
FireFox:
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
dimensions.
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
jQuery or another JavaScript abstraction library to normalize the DOM
model."
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
other browsers.
"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
$(window).width(), $(window).height()"
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
quirks mode).
"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
model bug".
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
clientWidth"
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.