4 ms·

Scrolling is completely broken. :/ (But this looks awesome!!)

by shocks 11y ago

azeirah 11y ago
It's using drag to scroll
- mikeyd 11y ago
  Otherwise known as "broken".
- yellowapple 11y ago
  It shouldn't, since the implementation breaks text selection and actual scrolling for desktop users.
- Gigablah 11y ago
  Why are people downvoting this person for stating a fact?
  - yellowapple 11y ago
    Because it's a shitty excuse for deliberately breaking UX. Because it's an indication that the designer believes he/she knows better than the OS programmers, the browser programmers, and the user when it comes to site ergonomics when said belief is demonstrably misguided. Because it doesn't fix the problem.
    - Gigablah 11y ago
      You are not answering my question. Why are people downvoting azeirah when azeirah isn't the designer of the site, and is not even advocating the design of the site?
grkvlt 11y 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 11y 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 11y 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 11y 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 11y 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.

Scrolling is completely broken. :/ (But this looks awesome!!)

by shocks 11y ago

Scrolling is completely broken. :/ (But this looks awesome!!)

azeirah 11y ago

It's using drag to scroll

mikeyd 11y ago
Otherwise known as "broken".
yellowapple 11y ago
It shouldn't, since the implementation breaks text selection and actual scrolling for desktop users.
Gigablah 11y ago
Why are people downvoting this person for stating a fact?
- yellowapple 11y ago
  Because it's a shitty excuse for deliberately breaking UX. Because it's an indication that the designer believes he/she knows better than the OS programmers, the browser programmers, and the user when it comes to site ergonomics when said belief is demonstrably misguided. Because it doesn't fix the problem.
  - Gigablah 11y ago
    You are not answering my question. Why are people downvoting azeirah when azeirah isn't the designer of the site, and is not even advocating the design of the site?

grkvlt 11y 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 11y 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 11y 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 11y 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 11y 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.