jamesflorentino / nanoScrollerJS

A jQuery plugin that offers a simplistic way of implementing Lion OS scrollbars.
http://jamesflorentino.github.com/nanoScrollerJS/
MIT License
2.69k stars 504 forks source link

webkit destroy #296

Open commonpike opened 9 years ago

commonpike commented 9 years ago

If I use the destroy method on webkit, it doesnt really restore the original scrollbar. In fact, before I activate nanoscroll, the scrollbar is already gone through the default css

.nano > .nano-content::-webkit-scrollbar { display: none; }

(what I'm trying to do, is enable nano on certain OSs only. webkit on mac has a nice scrollbar that I dont want to replace. as in if (youwantnano) $('.nano').nanoScroller() - but it breaks webkit)

kristerkari commented 9 years ago

Yeah you are correct. Maybe we need to set the CSS styling for that from the JS side instead.

commonpike commented 9 years ago

I tried that, its tricky. On initialisation of the widget, the lib checks for BROWSER_SCROLLBAR_WIDTH by comparing outer.offsetWidth to outer.clientWidth on a created div with overflow. Within that div, I think the same css rules should apply as on the actual widget. In webkit on my mac, the scrollbar shows and hides using its own magic, and seems to be detected as width 0, regardless of css. the negative right margin is not set and the .has-scrollbar class not added. That behaves if the css is set. If it isnt, sometimes the native scrollbar suddenly pops up and appears beneath the nano scrollbar (it shines through - looking very much alike).

whats tricky is removing the ::-webkit-scrollbar { display: none; } rule. if you set it to display:block it displays as a big white bar with no thumb. it seems to have lost its -webkit-appearance or something...

kristerkari commented 9 years ago

@commonpike Thanks for looking at this!

whats tricky is removing the ::-webkit-scrollbar { display: none; } rule. if you set it to display:block it displays as a big white bar with no thumb. it seems to have lost its -webkit-appearance or something...

Good to know, I need to run some tests to see how it behaves.

commonpike commented 9 years ago

may actually want to try .element::-webkit-scrollbar { width: 0 !important } instead of display:none ...

commonpike commented 9 years ago

And, this could very well be my chrome/macos, but .. I tried to set things about ::-webkit-scrollbar with javascript, but it had no effect until I said anything about ::-webkit-scrollbar in real css first. Things start working when I set, for example ::-webkit-scrollbar { z-index:1; } in the head of the page (or using document.write() while loading the page).

but then, doing that makes the scrollbar appear as a big white bar again, unless you hide it.

What I'm guessing is, that the autohiding feature manipulates css from the chrome engine, and whatever you change gets overridden once the scrollbar shows or hides. setting something in the 'real' css first seems to disable the autohiding, allowing you to continue styling in javascript. But thats a guess.

commonpike commented 9 years ago

I end up doing the same as what you do for isFFWithBuggyScrollbar(). actually, i dont think its buggy. the scrollbar on that browser/os is overlapping the content, so its technically 0 px wide. Chrome does the same. Unfortunately, ff has no css to hide the scrollbar, so you guess its 14px and push it out of the container.

but whatever I do, I cant properly hide / unhide the scrollbar in webkit either. So I do the same ...