[webkit-dev] Expected behavior of "scrolling" attribute for IFrame element

[Darin Adler]

On Jun 13, 2011, at 11:05 AM, Ojan Vafai wrote:

> On Mon, Jun 13, 2011 at 10:51 AM, Darin Adler <darin at 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.

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