according to scott gonzalez, this has been a known limitation for some time, but just not documented. in that case, it might just be a needsdoc. i am following up with brandon aaron, however, to see what the limitation is that is preventing us from taking border/margin/padding on the body into account and whether it is surmountable.

thanks for taking the time to file a ticket!

I haven't looked back into this in some time. However, the offset method in dimensions used to take these factors into account and it was A LOT of code (see also forking and browser detection) to properly support it with all its quirks. Adding border/margin/padding to the body had very different results in the browsers depending on other conditions of the element. Here is an example from the original dimensions offset method:

// Mozilla does not include the border on body if an element isn't positioned absolute and is without an absolute parent
if (mo && parPos == 'absolute') absparent = true;
// IE does not include the border on the body if an element is position static and without an absolute or relative parent
if (ie && parPos == 'relative') relparent = true;

and another example

// Safari 2 and IE Standards Mode doesn't add the body margin for elments positioned with static or relative
if (((sf && !sf3) || (ie && $.boxModel)) && elemPos != 'absolute' && elemPos != 'fixed') {
    x += num(parent, 'marginLeft');
    y += num(parent, 'marginTop');
}
// Safari 3 does not include the border on body
// Mozilla does not include the border on body if an element isn't positioned absolute and is without an absolute parent
// IE does not include the border on the body if an element is positioned static and without an absolute or relative parent
if ( sf3 || (mo && !absparent && elemPos != 'fixed') || 
     (ie && elemPos == 'static' && !relparent) ) {
    x += num(parent, 'borderLeftWidth');
    y += num(parent, 'borderTopWidth');
}

Based on my previous experience in supporting this, the limited number of people actually styling the body element, and the simple workaround of using a nested div instead... I decided to not support this when moving dimensions to core.

thanks for chiming in brandon. i personally am not convinced we shouldn't support this in core - but others probably have their own opinions. please do share your thoughts here...

My personal take on this is that where some behavior is not used by a significant number of users (I'm both a designer and developer and have probably only seen this twice ever), it may not be the in the best interests of the project to invest time (and more importantly additional bytes/kbs to jQuery) to support it. Brandon's thoughts when initially looking at the problem (ie. a nested div workaround) probably sound like a reasonable alternative to suggest.

Just my two cents :)

Personally, I was able to work around this by using jQuery UI's position() method.

My alternatives were to manually add the border width myself, or set the border on a div instead of the body.

Obviously I'd be in favor of this being fixed ... but if it's not worth the effort some sort of note about this in the documentation is probably worth adding.

Before I asked about this IRC I went to the docs and even looked through the comments and didn't see any notice about this problem.

CCing Scott Gonzalez for his thoughts on this as he may have more knowledge on position() than the rest of us. Scott, do you think this should be a fix or wontfix?

Jaubourg, DaveMethvin, scott_gonzalez and I discussed this and we think that given the perf-hits that would be involved in supporting this, we're currently happier providing detailed documentation on why it isnt supported instead of making all users suffer the delay in page load. If someone wants to make a case for it being included or has an idea for how it could be achieved in an optimal fashion, please feel free to re-open.