Document.Body.Scrollheight Yielding Two Different Results in Firefox/Chrome

iframe height cut off

In Firefox you need to query documentElement.scrollHeight instead of body.scrollHeight


Methods to automatically choose the correct property can be found in

.body.scrollHeight doesn't work in Firefox or

document.body.scrollHeight yielding two different results in firefox/chrome

How do I get the height of a div's full content with jQuery?

scrollHeight is a property of a DOM object, not a function:

Height of the scroll view of an element; it includes the element padding but not its margin.

Given this:

<div id="x" style="height: 100px; overflow: hidden;">
<div style="height: 200px;">
pancakes
</div>
</div>

This yields 200:

$('#x')[0].scrollHeight

For example: http://jsfiddle.net/ambiguous/u69kQ/2/ (run with the JavaScript console open).

How can I check if a scrollbar is visible?

a little plugin for it.

(function($) {
$.fn.hasScrollBar = function() {
return this.get(0).scrollHeight > this.height();
}
})(jQuery);

use it like this,

$('#my_div1').hasScrollBar(); // returns true if there's a `vertical` scrollbar, false otherwise..

tested working on Firefox, Chrome, IE6,7,8

but not working properly on body tag selector

demo


Edit

I found out that when you have horizontal scrollbar that causes vertical scrollbar to appear, this function does not work....

I found out another solution... use clientHeight

return this.get(0).scrollHeight > this.get(0).clientHeight;

Should you design HTML and CSS layouts using primarily margin/padding or positioning?

For a typical page layout, Example 1 is much cleaner and you should choose that, given the choice.

Example 2 is bad because as soon as you start setting position: absolute on everything, any flexibility your design may have had goes out the window. You have to set explicit dimensions on everything.

In general (there are exceptions), avoid position: absolute for the main layout unless it's only way to do it.

Here's an example of the kind of problem I was talking about. It would appear that the user ended up using JavaScript to fix his problems. Not good.

how to get the browser window size without the scroll bars

function getScrollBarDimensions(){
var elm = document.documentElement.offsetHeight ? document.documentElement : document.body,

curX = elm.clientWidth,
curY = elm.clientHeight,

hasScrollX = elm.scrollWidth > curX,
hasScrollY = elm.scrollHeight > curY,

prev = elm.style.overflow,

r = {
vertical: 0,
horizontal: 0
};

if( !hasScrollY && !hasScrollX ) {
return r;
}

elm.style.overflow = "hidden";

if( hasScrollY ) {
r.vertical = elm.clientWidth - curX;
}

if( hasScrollX ) {
r.horizontal = elm.clientHeight - curY;
}
elm.style.overflow = prev;

return r;
}

Running getScrollBarDimensions(); on this page yields:

Object
horizontal: 0
vertical: 17

for me in google chrome, IE7, opera and firefox.

Check if element is visible in DOM

According to this MDN documentation, an element's offsetParent property will return null whenever it, or any of its parents, is hidden via the display style property. Just make sure that the element isn't fixed. A script to check this, if you have no position: fixed; elements on your page, might look like:

// Where el is the DOM element you'd like to test for visibility
function isHidden(el) {
return (el.offsetParent === null)
}

On the other hand, if you do have position fixed elements that might get caught in this search, you will sadly (and slowly) have to use window.getComputedStyle(). The function in that case might be:

// Where el is the DOM element you'd like to test for visibility
function isHidden(el) {
var style = window.getComputedStyle(el);
return (style.display === 'none')
}

Option #2 is probably a little more straightforward since it accounts for more edge cases, but I bet its a good deal slower, too, so if you have to repeat this operation many times, best to probably avoid it.

Object Initialization and Named Constructor Idiom

Unfortunately there's no direct support for this in C# 3.0. Object initializers are only supported for constructor calls. However, you might consider the Builder pattern. In my Protocol Buffers port, I support it like this:

MyType foo = new MyType.Builder {Parameter1 = 10, Parameter2 = 20}.Build();

So your example would become:

MyObjectValues.Select(currentItems => new MyType.Builder
{
Parameter1 = currentItems.Value1,
Parameter2 = currentItems.Value2
}.Build());

Of course, it means writing the nested Builder type, but it can work quite well. If you don't mind MyType being strictly speaking mutable, you can leave an immutable API but make an instance of Builder immediately create a new instance of MyType, then set properties as it goes (as it has access to private members), and then finally return the instance of MyType in the Build() method. (It should then "forget" the instance, so that further mutation is prohibited.)



Related Topics



Leave a reply



Submit