On Mon, Jun 13, 2011 at 11:21 AM, Darin Adler <da...@apple.com> wrote:
> On Jun 13, 2011, at 11:05 AM, Ojan Vafai wrote: > > On Mon, Jun 13, 2011 at 10:51 AM, Darin Adler <da...@apple.com> wrote: > >> Even though we need to prevent find or autoscrolling from scrolling, it > seems we must not prevent explicit programmatic scrolling. I’ll add a > comment to the bug about this. > > > > overflow:hidden divs are used to implement custom scrollbars. While > find-in-page breaking wouldn't be too bad, breaking autoscrolling on these > sites would likely require us to rollback the change. Maybe we should expose > an attribute or CSS property to allow controlling this to give sites a > workaround? > > Could be. > > I guess at root this is a user interface problem. Scrolling something if > there is no UI for scrolling back is a problem. Similarly, scrolling > something into view that a developer thinks is invisible is a problem. I > guess the browser does need some way to tell if the user can scroll back, so > it can various forms of scrolling in those cases. > > It would be best if we could correctly do this even on existing sites, but > I don’t have any ideas about how to tell cases where a scroll would be a bad > idea from cases where a scroll would be OK. > I agree. I think it would be fine to disable autoscroll for overflow:hidden by default if we give a way for sites to turn it back on. Implementing custom scrollbars is often a bad idea for websites that want to > work well on platforms like Mac OS X Lion with a modern input device and iOS > that don’t have conventional scrollbars. Not sure how to promulgate the best > practices here. > Yeah. I can't think of a way to improve the situation beyond just giving developers control over autoscroll. Just curious: On the sites you know of that do this to implement custom > scrollbars, do they use the scroll event to update the scrollbars when > scrolling is done by the browser engine? > I'm not sure. The only real-world case of this I can think of is Google Wave. I'm not sure what their implementation is like though. > -- Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev