newer (e.g. 31) Chromes complain about what to scroll

[szepeviktor]

body.scrollTop is deprecated in strict mode.
Please use 'documentElement.scrollTop' if in strict mode and 'body.scrollTop' only if in quirks mode.
jquery.scrollTo-amd.min.js:1

Please distinguish between old and new webkits.

(and you may use "use strict";)

[flesler]

That's a warning that pops in the console?

[szepeviktor]

ofcourse

[nitriques]

See https://twitter.com/derickbailey/status/425299085537460224

[szepeviktor]

Then it is OK now.
I do not care about the console.

[nitriques]

I do not care about the console.

You should.

[tmorehouse]

I've seen other similar error from jQuery itself in the console log. Right now they are just warnings. so nothing major to to worry about.

[szepeviktor]

I mean this console message.
Or should this webkit condition be deleted?
https://github.com/flesler/jquery.scrollTo/blob/master/jquery.scrollTo.js#L48

[tmorehouse]

maybe change it to:

return (document.body.scrollTop) ? document.body : document.documentElement;

[szepeviktor]

That may cause an error.
return (document.documentElement.scrollTop) ? document.documentElement : document.body;

[tmorehouse]

Maybe:

return (document.documentElement && document.documentElement.scrollTop) ? 
    document.documentElement : document.body;

[flesler]

Let's keep this open, I'm afraid nothing might work once Chrome 33 is released

[flesler]

Maybe $(window).scrollTop() will do? not sure, need to do some research.
I appreciate if you guys help out.

[nitriques]

@flesler

Maybe $(window).scrollTop()

I ALWAYS use that. Never body, nor html. If it's on part of the document, it's always a div.

[szepeviktor]

jQuery 1.10.2

// Create scrollLeft and scrollTop methods
jQuery.each( {scrollLeft: "pageXOffset", scrollTop: "pageYOffset"}, function( method, prop ) {
    var top = /Y/.test( prop );

    jQuery.fn[ method ] = function( val ) {
        return jQuery.access( this, function( elem, method, val ) {
            var win = getWindow( elem );

            if ( val === undefined ) {
                return win ? (prop in win) ? win[ prop ] :
                    win.document.documentElement[ method ] :
                    elem[ method ];
            }

            if ( win ) {
                win.scrollTo(
                    !top ? val : jQuery( win ).scrollLeft(),
                    top ? val : jQuery( win ).scrollTop()
                );

            } else {
                elem[ method ] = val;
            }
        }, method, val, arguments.length, null );
    };
});

function getWindow( elem ) {
    return jQuery.isWindow( elem ) ?
        elem :
        elem.nodeType === 9 ?
            elem.defaultView || elem.parentWindow :
            false;
}

[flesler]

I think you can see the warning by using vanilla jQuery. Not sure the core implementation is the solution.

[tmorehouse]

I see jQuery throwing the same error once and a while, just by itself.

[tmorehouse]

http://dom.spec.whatwg.org/#concept-document-quirks

you could maybe do a test on document.compatMode. If it exists and has a value of CSS1Compat then scroll the documentElement, otherwise revert to scrolling the body element.

The "strict mode" chrome is referring to is not use strict, but rather the rendering mode of the browser (based on the DOCTYPE)

change this:

return /webkit/i.test(navigator.userAgent) || doc.compatMode == 'BackCompat' ?
    doc.body : 
    doc.documentElement;

to this maybe:

return doc.compatMode && doc.compatMode == 'CSS1Compat' ?
    doc.documentElement :
    doc.body;

[flesler]

I'll try this fix when I get home

facebook/react#643

Also I'll take from jQuery's code, the one Viktor posted.

On Fri, Jan 24, 2014 at 12:54 PM, Troy Morehouse
notifications@github.comwrote:

http://dom.spec.whatwg.org/#concept-document-quirks

you could maybe do a test on document.compatMode. If it exists and has a
value of CSS1Compat then scroll the documentElement, otherwise revert to
scrolling the body element.

The "strict mode" chrome is referring to is not use strict, but rather
the rendering mode of the browser (based on the DOCTYPE)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-33234233
.

Ariel Flesler

[flesler]

Ok, I've been doing some experiments on Windows 7.
Updated the tests to use the latest version of jquery, you can try them yourself.
The results were unexpected.

Chrome 32 shows a warning when on compatibility mode as expected:

Chrome 33 beta actually showed no warning and worked with the current version of scrollTo just fine:

I tried using the documentElement on all cases and then on compat mode, Chrome 33 didn't work at all.
So the lesson is, Chrome 33 beta only works with the body which is the way it is right now.

@szepeviktor @nitriques @tmorehouse @Mithgol
I encourage you to try it yourself on other platforms and browsers let me know what you get.

[nitriques]

Thanks @flesler
I will test tomorrow!

[flesler]

How did it go @nitriques ?
Can you guys take a look too? @szepeviktor @tmorehouse @Mithgol

[nitriques]

Chrome 32 still complains in WinMaxY-compat.html.
But Chrome 34 (canary) does not.

[flesler]

Good, same as me. Thanks.

[nitriques]

You're welcome :)

[flesler]

Well, closing this. Reopen if something else related comes up