On Jun 13, 2011, at 11:05 AM, Ojan Vafai wrote:
> On Mon, Jun 13, 2011 at 10:51 AM, Darin Adler <[email protected]> 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.
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.
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?
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
