|Summary:||FlexScroll Custom Scrollbars don't work with Safari|
|Product:||WebKit||Reporter:||Dave Hyatt <email@example.com>|
|Component:||Layout and Rendering||Assignee:||Nobody <firstname.lastname@example.org>|
|Severity:||Normal||CC:||email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org|
|OS:||Mac OS X 10.4|
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.
(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.
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 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.
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.