Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating gh-pages branch to latest master (fixes #60) #66

Open
wants to merge 62 commits into
base: gh-pages
Choose a base branch
from

Conversation

2is10
Copy link
Contributor

@2is10 2is10 commented Jun 21, 2013

This will get the demo working again. Need to merge next pull request too. Fixes #60.

rauchg and others added 30 commits November 23, 2011 14:27
Style caching was a precaution, in order to reset the styles to their previous values
before calling the Antiscroll constructor.

Now, this will not work anymore:

    var containers = $('.container');
    containers.find('.antiscroll-inner').css('background', 'red');
    // The background is red
    containers.antiscroll();
    containers.each(function(){
      $(this).data('antiscroll').rebuild();
    });
    // The red background is removed

But if we assume that:

 - It is an expensive operation
 - <div class="antiscroll-inner"> is supposed to be dedicated to
   antiscroll
 - Styles can still be added between the calls to antiscroll() and
   rebuild(), and will not be cached

It’s relatively safe to remove it.
improvement options parameter
If scrollbar size is 0 we were computing it every time scrollbarSize was
called. It's especially wastefull on webkit browsers were scrollbar size
can be set to 0 through CSS.
Optimize scrollbar size computing
Hard to see scrollbar when using darker background color.
…d Digital Color meter, and they are the exact same f'n color!
I noticed the shade of the scrollbars was a hair off native....
@guille, I measured the hover color, 0.04 alpha off. LOLZ
Set this.horizontal and this.vertical properties to null when destroyed
and unbound scroll and mousewheel event listeners tied to the scrollbar
when it is destroyed.
arlm and others added 24 commits October 29, 2012 10:36
* Coding style fixes
* options.Force refactoring
Antiscroll stopped working properly in Chrome v25 (it's still in dev
channel). For some reason native scrollbars are displayed under
the antiscroll generated scrollbars. The browser behaves as if ::scrollbar pseudo class
styles (setting scrollbar width/height to 0) were ignored.

I am not really sure what's causing that, but when trying to investigate
the problem I realized that scrollbarSize did not work properly in
Chrome. It was returning 0 and not the native scrollbar width.
We now calculate the size in the container with 'antiscroll-inner' class
applied. If ::scrollbar CSS is applied properly the width is 0, and we
don't have to hide native scrollbars manually. Otherwise scrollbars are
hidden by adjusting .antiscroll-inner size. That fixes Chrome v25
issue.
Explaining Installation and Configuration
A lot of fixes and improvements
antiscroll does not work with chrome Version 25.0.1323.1 dev
A bug in Chrome 25 on Lion requires each selector to have their own blocks. E.g. the following:

.antiscroll-inner::-webkit-scrollbar, .antiscroll-inner::scrollbar {...}

causes the width and height rules to be ignored by the browser resulting in both native and antiscroll scrollbars appearing at the same time.
Calculate needXScroll with scrollbarSize
Give scrollbar pseudo-classes their own blocks, fixes issue #46
Fix adding scrollbar dimension twice.
@2is10
Copy link
Contributor Author

2is10 commented Jun 21, 2013

May I ask why the gh-pages branch is so far behind to begin with? Is it intentional?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.