window.innerWidth
window.innerHeight

• iPhone gives the dimensions of the current zoom area.
• Blackberry gives an innerHeight that’s larger than the total screen height.
• Bolt gives weird numbers that are larger than the reported screen.width/height.

window.outerWidth
window.outerHeight

• iPhone always gives 320 x 396 independent of orientation
• Bolt gives weird numbers. The 400 for the outerWidth is definitely incorrect.

window.pageXOffset
window.pageYOffset

• iPhone counts a zoom as a scroll.

window.screenX
window.screenY

On mobiles we generally expect the value 0 because the browser screen takes the entire screen.

• Iris’ screenY of 52 is incorrect.
• Android gives the same values as pageX/YOffset

screen.availWidth
screen.availHeight

screen.colorDepth

screen.pixelDepth

The difference between colorDepth and pixelDepth is only important on (older?) Unix machines, where old X-clients may allow applications to define their own color scheme. If that’s the case, colorDepth matches the color depth of the application and pixelDepth the color depth of the monitor. In all other cases they’re equal.

screen.width
screen.height

• I distrust Bolt’s 800x800, because the screen is not square and these numbers don’t agree with the page width and height.
• I also distrust Iris’ 640x480.

document.elementFromPoint(100,100)

Which coordinates does elementFromPoint() need? In general browsers work with clientX/Y.

Alternative: Browser uses pageX/Y instead.

• Opera reports a text node whenever possible, while this method should report the containing element node.
• Iris always reports the HTML element.

This method is a godsend for drag and drop scripts. When the user drops the dragged element, figure out what element is located at the drop point and go on from there. No more complicated calculations necessary.

However, you need to temporarily hide the dragged object. By definition it's the topmost element on the requested coordinates, and we need to know what's underneath it. The basic trick is:

releaseElement: function(e) { // called onmouseup
	var evt = e || window.event;
	draggedObject.style.display = 'none';
	var receiver = document.elementFromPoint(evt.clientX,evt.clientY);
	if (receiver.nodeType == 3) { // Opera
		receiver = receiver.parentNode;
	}
	draggedObject.style.display = '';
	

Now receiver contains the element the user dropped the dragged element on.

x.getBoundingClientRect()

Returns an object that contains the top, left, right, and bottom (all relative to the top left of the viewport) of the combined rectangle of element x. Essentially, the browser calculates all rectangles (see below getClientRects()), and getBoundingClientRect() returns the lowest (top, left) or highest (bottom, right) values found.

IE handles this correctly, provided you accept its incorrect calculation of the individual rectangles.

• Firefox doesn't round the top/bottom coordinates.
• I think Opera HTC does this right, but it reacts so poorly to the test that I can’t say for sure.

x.getClientRects()

Returns a list with Rectangle objects that contain the top, left, right, and bottom (all relative to the top left of the viewport) of the rectangles of element x.

The trick here is, that an inline element such as an <em> contains one rectangle for every inline box (line), and that all these rectangles are returned.

• Firefox doesn't round the top/bottom coordinates.

x.scrollIntoView()

Element x scrolls into view.

Essentially element x behaves as if it's the target of an #hash: it scrolls to the topmost, leftmost position allowed.

• Incomplete: browser handles the Y-coordinate correctly, but it also scrolls to the left edge of the page, which can make this method hard to use when the user has zoomed in.

x.clientLeft
x.clientTop

x.clientWidth
x.clientHeight

• Bolt counts the scrollbars as part of the clientWidth/Height.
• Android G1 subtracts space for scrollbars even though it doesn’t show any.

x.offsetLeft
x.offsetTop

x.offsetParent

When calculating the offsetParent of x the browser moves up the DOM tree to x's ancestors until it encounters one of the following elements. That element becomes x's offsetParent.

• <body>
• An element with a position other than static.
• A <table>, <th> or <td>, but only if x has position: static.

The <body> element does not have an offsetParent. Nonetheless the <html> element sometimes enters the offsetParent chain, though never as the offsetParent of the <body>.

In IE and Opera elements with position: fixed do not have an offsetParent.

• Blackberry takes the text node as a target, which messes up my test script. It also always reports table elements, even if the target does not have position: static.

x.offsetWidth
x.offsetHeight

• Blackberry only measures content width and height.

x.scrollLeft
x.scrollTop
x.scrollTop = 20

I consider 0 correct if the browser is unable to scroll elements with overflow: auto, and incorrect if it is able to do so.

x.scrollWidth
x.scrollHeight

When you scroll the element all the way down, scrollHeight should be equal to scrollTop + clientHeight.

If the element has no scrollbars scrollWidth/Height should be equal to clientWidth/Height.

• When the element has no scrollbars IE makes the scrollHeight equal to the actual height of the content; and not the height of the element. scrollWidth is correct, except in IE8, where it’s 5 pixels off.
• Opera doesn't include the element's padding.
• NetFront SE C510 always makes scrollWidth/Height equal to offsetWidth/Height.