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

webkit destroy #296

Open
commonpike opened this issue Apr 15, 2015 · 6 comments
Open

webkit destroy #296

commonpike opened this issue Apr 15, 2015 · 6 comments

Comments

@commonpike
Copy link

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 kristerkari added this to the 0.8.7 milestone Apr 17, 2015
@kristerkari
Copy link
Collaborator

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

@commonpike
Copy link
Author

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
Copy link
Collaborator

@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
Copy link
Author

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

@commonpike
Copy link
Author

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
Copy link
Author

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 ...

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

No branches or pull requests

2 participants