These work with Opera, Firefox and WinIE. See: http://www.hesido.com/web.php?page=customscrollbar It could be something wrong with the scripts, or it could be our bug. Someone needs to reduce it.
Created attachment 6398 [details] Testcase reduction (partly) In JavaScript, changing the div's overflow to "hidden" has no effect if offsetHeight has been called on the div before. Firefox 1.5 and Opera 9 hides the scroll bar, Safari doesn't. This seems to be a small part of the reported bug.
(In reply to comment #0) > These work with Opera, Firefox and WinIE. See: > > http://www.hesido.com/web.php?page=customscrollbar > > It could be something wrong with the scripts, or it could be our bug. Someone needs to reduce it. Hi, I am the author of the script. From until version 1.1.0, I started doing a Safari block by default so Safari users can browse the contents without problems. For easy testing, I am leaving a no-block version at this address: http://www.hesido.com/web.php?page=customscrollbarsafariunblock I don't have a Mac to do any further reduction. I'd appreciate any feedback.
Ok, this first bug is fixed.
And that was the whole issue. The native bars were just obscuring the non-native ones. It's all good now.
Thanks for the information. I will remove the Safari block with the next update.
Actually you could work around the bug now I suspect if you just don't do the auto->hidden swap. In Safari only just start off with the overflow sections set to hidden.
I updated the script to set the div to overflow:invisible without first reading its size with offsetWidth/Height, and only afterwards (updated the no-safari block page,1.6.2 beta1), but my friend reports that it still doesn't work (he hasn't downloaded any Safari updates). I have to set the overflow:invisible within the script or otherwise people can't access the sites content without javascript turned on, overflow has to be auto for people without javascript. I may try going for bug detection, and I think I'll have to keep the block until I come up with a solution to keep older Safari's happy. Any suggestion is welcome.
Latest Safari release and latest WebKit before this fix already show different behaviour using your scrolls. Especially, the top right box can be scrolled with the latter, since the scroll bar isn't completetly obscured by the native scroll bar. This might imply that there were another, now fixed, bug between latest release and latest nightly, that your scrolls needed fixed. I understand your decision wrt going from auto to hidden in javascript, but I don't know how to work around old Safaris bugs. Just so you know, even if it's fixed in WebKit doesn't mean Safari immediately gets the fix. Safari updates usually come with OS X 10.x.x updates, which are a couple months between. Also, I think there is no knowing if this very bug fix gets into such an update, well maybe unless you are Apple. And then there is the state of Safari on 10.3, of which I know little (don't know if only security fixes go there, or other fixes also). All in all, I think that if you want as many as possible to be able to interact with your pages, you should wait until a released version of Safari supports the custom scroll bars, and then sniff for that version number, blocking earlier versions. Unless you find a workaround, of course.
I finally got around detecting newer Safari's (>2.0.4), and implemented it on http://www.hesido.com/web.php?page=customscrollbarsafariblocktest as beta. I thought of bug detection but that would elongate the code a lot, so I simply went for HTMLElement and HTMLElement.prototype detection on top of the simple user-agent Safari detect, which allowed me to run fleXcroll on new webkits, while successfully blocking old Safari's with the fewest line of code. I'd appreciate if you could do some testing, I am testing using a VNC server and I could only get thus far.
There's info here about how to detect WebKit using JavaScript in case you're interested: http://trac.webkit.org/projects/webkit/wiki/DetectingWebKit
Thanks David, I had already seen that and would resort to that method had HTMLElement.prototype not been implemented on new webkits. I had to go for the simpler approach of browser capability, with the fewest size overhead. I think many script author's would do the same instead of messing with version numbers. I am hoping new bugs are not introduced of course. Safari 3.0 will be what matters.