3 ms·

I keep reading these comments on HN, but for me, I have never experienced a 'broken' scrolling effect. I browse using Chrome on OSX using: 1. my laptop touchpad

by grkvlt 12y ago

I keep reading these comments on HN, but for me, I have never experienced a 'broken' scrolling effect. I browse using Chrome on OSX using: 1. my laptop touchpad and two-finger dragging, 2. the up/down arrow keys, 3. the spacebar, or 4. the scroll-wheel on my mouse. On my phone I use Android Chrome and scroll by dragging up and down. Anyway, I can't remember ever having these techniques not work. Is there some other way of scrolling that I haven't thought of, and therefore am not using day-to-day, that breaks for other people, or do I just put up with it unconciously, switching between methods 1-4 automatically on the laptop, and never notice? Or, are people using iPads or iPhones, which I do not own, and they are more susceptible? Or Browsers-other-than-Chrome, which I guess must exist ;) Genuinely curious!

jabuti 12y ago
I'm using Firefox on OSX. It scrolls extremely slow using a mousewheel. It also won't scroll when the mouse pointer is over the Vimeo embed (with the mousewheel or touchpad)
- freditup 12y ago
  Also, the pageup and pagedown keys don't move the page. Also, the arrow keys don't move the page. Also, I can't seem to scroll by clicking on the scrollbar thumb and dragging it. Very frustrating indeed on FF on a desktop.
Trufa 12y ago
Anything that modifies the native scrolling of a website can make a lot of trouble for some users, it's sometimes laggy, slow, or you simply can't scroll, it's a dangerous game. Though we could discuss it all night long, in this particular case, people seem to be complaining about a chrome bug that doesn't let you scroll at all after you've done certain things ( can't really find steps to reproduce). Which brings us again to the dangers of playing with scroll. Chrome on OSX and chrome on android are quite the majority (and sometimes over represented on web-devs) so maybe that's why you don't see much issues. This issue in particular happens to me with Chrome in Ubuntu.
pdkl95 12y ago
Nothing in the DOM spec indicates that there are scroll bars or anything else about how the user is interacting with the scrolling position of the page. The window.scroll* functions talk about pixel or line dimensions, and not how the user's scrolling interface works or how the user interacts with that interface. For example, some common methods are: * scrolling with a mouse by clicking on a traditional scrollbar (this is what is being reimplemented) * using a scroll wheel or trackpad drag (compatibility is *often* added for this, but not always) * dragging touchscreen (support varies, getting better) * using the arrow keys (sometimes supported) ..and a few of that almost always break when scrolling isn't left to the user agent: * PageUp/PageDn * some other key to page down, such as the space bar * a browser extension to auto-scroll the page slowly * accessibility tools of various types * no javascript support * the foot pedal I made out of MIDI keyboard sustain pedals and an old USB keyboard that is mapped to a non-standard X KeySym and bound as an alias to PageDn in firefox (it's Meta in emacs) * the scrolling UI for next year's Cool New Gadget that we cannot support because the device doesn't exist yet, but the manufacturers of the device can add support for standard HTML/DOM features Also, even in the case where the UI method is guess correctly, the details may be different. For example, I set firefox's mousewheel.default.delta_multiplier_y to 500 so each scroll wheel click is a much larger movement of the page, because my mouse wheel is not a mouse wheel - I use thumb buttons for scrolling because the normal wheel was causing RSI problems. The basic problem is a common misconception about what HTML, where the client (via their User Agent) controls the presentation. As they are in the hands of the users, there will always be a lot of variation as those users tailor their tools to their personal needs. The only way to maintain any particular presentation feature across all clients is to turn the WWW back into TV. The alternative is learning what can be specified by the page (pixel scroll position) and what is NOT in the spec (how the user and their User Agent interact), while remembering that any of these features may not be implemented the way you think they are.

by grkvlt 12y ago

jabuti 12y ago

I'm using Firefox on OSX. It scrolls extremely slow using a mousewheel. It also won't scroll when the mouse pointer is over the Vimeo embed (with the mousewheel or touchpad)

freditup 12y ago
Also, the pageup and pagedown keys don't move the page. Also, the arrow keys don't move the page. Also, I can't seem to scroll by clicking on the scrollbar thumb and dragging it. Very frustrating indeed on FF on a desktop.

Trufa 12y ago

Anything that modifies the native scrolling of a website can make a lot of trouble for some users, it's sometimes laggy, slow, or you simply can't scroll, it's a dangerous game. Though we could discuss it all night long, in this particular case, people seem to be complaining about a chrome bug that doesn't let you scroll at all after you've done certain things ( can't really find steps to reproduce). Which brings us again to the dangers of playing with scroll. Chrome on OSX and chrome on android are quite the majority (and sometimes over represented on web-devs) so maybe that's why you don't see much issues. This issue in particular happens to me with Chrome in Ubuntu.

pdkl95 12y ago

Nothing in the DOM spec indicates that there are scroll bars or anything else about how the user is interacting with the scrolling position of the page. The window.scroll* functions talk about pixel or line dimensions, and not how the user's scrolling interface works or how the user interacts with that interface. For example, some common methods are: * scrolling with a mouse by clicking on a traditional scrollbar (this is what is being reimplemented) * using a scroll wheel or trackpad drag (compatibility is *often* added for this, but not always) * dragging touchscreen (support varies, getting better) * using the arrow keys (sometimes supported) ..and a few of that almost always break when scrolling isn't left to the user agent: * PageUp/PageDn * some other key to page down, such as the space bar * a browser extension to auto-scroll the page slowly * accessibility tools of various types * no javascript support * the foot pedal I made out of MIDI keyboard sustain pedals and an old USB keyboard that is mapped to a non-standard X KeySym and bound as an alias to PageDn in firefox (it's Meta in emacs) * the scrolling UI for next year's Cool New Gadget that we cannot support because the device doesn't exist yet, but the manufacturers of the device can add support for standard HTML/DOM features Also, even in the case where the UI method is guess correctly, the details may be different. For example, I set firefox's mousewheel.default.delta_multiplier_y to 500 so each scroll wheel click is a much larger movement of the page, because my mouse wheel is not a mouse wheel - I use thumb buttons for scrolling because the normal wheel was causing RSI problems. The basic problem is a common misconception about what HTML, where the client (via their User Agent) controls the presentation. As they are in the hands of the users, there will always be a lot of variation as those users tailor their tools to their personal needs. The only way to maintain any particular presentation feature across all clients is to turn the WWW back into TV. The alternative is learning what can be specified by the page (pixel scroll position) and what is NOT in the spec (how the user and their User Agent interact), while remembering that any of these features may not be implemented the way you think they are.