Thanks for providing a bug report :) Could you provide some examples of where this is? I see https://github.com/jquery/jquery/blob/master/src/event.js#L516

and while there are other tests involving scrollTop or similar, they are in a different context

I just searched for "body.scroll" in the jQuery 1.4.4 source code. So, if changes have been made to the 1.4.4 scrollTop/Left parts in the repository my numbers will be off.

Either way, it would be nice to be able to check which element is scrollable with a simple var scrollEl = $.support.documentElementScrolls ? "$("html") : $("body");.

musicisair, I wasn't just referring to the line numbers, but rather, the actual content of the source. Are you looking at the latest source code in the repo, or just the 1.4.4 release from the website?

As for adding to support, to me, it seems trivial to add something like that to core that could easily be done outside of the application or as a plugin.

Usually the guiding factor for whether something is added to jQuery.support is whether it is required in the core and provides a DRY improvement or performance boost. We often get requests to add support checks for features like SVG for example, but if we do that we'll be adding load-time overhead to every page for the few who need SVG detection. Core doesn't need SVG detection.

With those guidelines in mind, does this still make sense? Can you provide specific line references to the core code that would be improved?

I was just looking at the 1.4.4 release. It looks like the http://code.jquery.com/jquery-git.js version is the same (in regards to the scroll parts).

I'm just assuming the following sections can be DRYed with the $.support check. I haven't done any testing whatsoever. They first check if the documentElement has a scroll position and then check if the document.body has a scroll position.

• Lines 2336-2337
• Lines 7883-7884
• Lines 7958-7959

(http://code.jquery.com/jquery-git.js)

Also, finding the document's main scrolling element is not a trivial task.

You must:

• insert a block element to the document with a height greater than the document window (so we can scroll it).
• cache the initial

  scrollTop

  position
• scroll with

  ++scrollElem.scrollTop

  where

  scrollElem

  is either

  body

  or

  documentElement

• check if

  scrollElem.scrollTop

  value has changed
• reset the

  element.scrollTop

  to the original value
• then finally remove the block element.

Since jQuery is already performing the 2 most expensive operations (adding and removing a div) for the other support tests it should be relatively easy to add this check.

FYI: the reason we can't just do

 $("body,html").animate({"scrollTop",500},1000); 

is because Opera scrolls BOTH elements (or it used to, its been a while since I've tested it). It is also not all that efficient to try to animate both elements unnecessarily. :-)

I'm with danheberden on this one - although there are occasionally features and enhancements that might be trivial to add to core, we have to weigh up just how widely those changes might be used. I think this is an ideal candidate for a plugin.

dmethvin, what do you think about the line refs provided by musicisair?

Nobody seems particularly interested in taking charge on this one so I am going to close it as patchwelcome.

As far as “we can’t animate both because Opera scrolls both”—if this was the case then there would be a lot of broken positional code in jQuery, since, as has been pointed out in this ticket, we only use one or the other, not both. (I’m not saying it’s not true that this is the case, just that if it is, exclusive checks are insufficient.)

More info (http://msdn.microsoft.com/en-us/library/ms534393(v=vs.85).aspx):

With Microsoft Internet Explorer 6 and later, when you use the !DOCTYPE declaration to specify standards-compliant mode, this attribute applies to the HTML element. When standards-compliant mode is not specified, as with earlier versions of Windows Internet Explorer, this attribute applies to the BODY element, not the HTML element.

Also (http://www.greywyvern.com/code/opera/bugs/htmlbodyOverflow):

From the CSS2 specifications, section 11.1.1: Visual effects, Overflow and clipping, Overflow: (emphasis added)

UAs must apply the 'overflow' property set on the root element to the viewport. When the root element is an HTML "HTML" element or an XHTML "html" element, and that element has an HTML "BODY" element or an XHTML "body" element as a child, user agents must instead apply the 'overflow' property from the first such child element to the viewport, if the value on the root element is 'visible'. The 'visible' value when used for the viewport must be interpreted as 'auto'. The element from which the value is propagated must have a used value for 'overflow' of 'visible'.

Opera [< 11] treats a root element overflow value of auto the same as visible and allows the value applied to the <body> element (hidden) to apply to the viewport [...]