5 ms·

> and dont do stuff like hijacking the scroll, zoom or other common behaviours. The hijacking of scrolling pisses me off so god damn much that I've considered

> and dont do stuff like hijacking the scroll, zoom or other common behaviours. The hijacking of scrolling pisses me off so god damn much that I've considered building Firefox from source and modifying the code to completely eliminate a website's ability to set the scroll position.[0] Front end devs, I implore you. Stop acting like you think you know what the user wants in regards to scrolling behavior. Smooth scrolling already exists natively in every browser. There's no need to try to re-implement it in JavaScript. Your implementation will not work in every browser, and will only cause strange stuttering, bouncing, or even end up somehow completely disabling scrolling altogether. Do not try to get fancy and implement "momentum" into scrolling. You're changing a well-understood behavior into something that is unexpected and jarring, and likely it won't work anyways. Do not change the scrolling amount. My wheel sensitivity and browser setting are configured so that 1-click ~= 2.5 lines of scrolling. Do not impose your preference of 1 click ~= 1 line on me. You do not know better than me. And disabling zooming? WHO EVEN DECIDED THAT WEBSITES SHOULD BE ALLOWED TO DO THIS?! It destroys accessibility! Sometimes there's text or an image that's just a little too small to recognize. I'd pinch to zoom in...but some moron front-end dev has adopted the beyond-bone-headed mentality of "removing features is a feature!" and makes their site tell the browser to not allow zooming because...why? Someone please, tell me why. [0] I'm sure it's possible to write an extension that could do this, but any time you're manually setting the scroll position in code, you're bound to fuck it up. Rather just completely eliminate the ability to set the scroll position entirely.

fsckboy 3y ago
> Do not impose your preference of 1 click ~= 1 line excuse me, but no designer ever gave audience to such a sensible suggestion
zimpenfish 3y ago
> And disabling zooming? I had a weird experience with Google Groups recently - I zoomed in because the text was too small and ... the page resized the viewport to its original pixel size even though the font was scaling. Ended up with about 10 characters in an unscrollable viewport. HILARIOUS.
- aidenn0 3y ago
  I had the opposite problem with a web page the other day. When I zoomed in, the text resized itself to still fit the same amount of text in the viewport, but since other elements would zoom correctly, the more I zoomed in, the smaller the text got.
  - yencabulator 3y ago
    Yes, I see this paradoxical zoom behavior all the time. Alternate horror scenarios that are all too common: Zoom only to have one picture take over the whole page, pushing text off the side (not even down, off screen to the side). Zoom only to have the text immediately become wider than the screen, forcing you to scroll sideways for every single line.
paulddraper 3y ago
> And disabling zooming? WHO EVEN DECIDED THAT WEBSITES SHOULD BE ALLOWED TO DO THIS?! Applications such as maps, image editors, presentations, and flowcharts benefit from having control over zoom. (And you'll notice that almost every one of them does.) This of course is only one difference of many between "documents" and "applications" and the web is being used for both.
- _jal 3y ago
  Maps drive me fucking nuts, taking over zoom. As do nearly every other app that does it. They think they know what's good for me, and they don't, and it leads to me using them less. Yes, paper maps just work better for me a lot of the time. The only thing maps.app or Google maps are good for are finding places to spend money or driving to places to spend money. If you have any other spatial interests, they're almost pointless. I would happily run a build that removes this capability.
  - paulddraper 3y ago
    I would love to see your maps app that doesn't touch zoom.
    - throwaway14356 3y ago
      No offense, I had to try that.. https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE_elevation.jpg https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE_el... Look how fast and responsive it is!
      - aendruk 3y ago
        With progressive decoding and spatial range requests this could actually be a reasonable replacement for a slippy map.
      - paulddraper 3y ago
        I'll use it on my drive home.
shadowgovt 3y ago
> The hijacking of scrolling pisses me off so god damn much that I've considered building Firefox from source and modifying the code to completely eliminate a website's ability to set the scroll position.[0] That'll break just about every cloud logging UI I'm aware of, but what you do to your own UA is your business.
kyleyeats 3y ago
You're mad at the wrong people here. I've never met a frontend dev who doesn't hate moving stuff vertically or scrolljacking. It's the marketing people that want it.
- ncallaway 3y ago
  The one that hurt me the most was making a page that started at the bottom and scrolled up. I left a comment somewhere in the JavaScript apologizing for it.
  - eddd-ddde 3y ago
    I really want to know what was the reasoning they gave you to do that
depressedpanda 3y ago
> I'd pinch to zoom in...but some moron front-end dev has adopted the beyond-bone-headed mentality of "removing features is a feature!" and makes their site tell the browser to not allow zooming because...why? Someone please, tell me why. For sites that have no business disabling zoom: no idea, and it annoys me too. I just chalk it up to dev, designer and/or managment incompetence, close the tab and never return again. /Moron frontend dev
drewrbaker 3y ago
As the poor sap who’s had to build lots of these types of sites, I’ll tell you that it’s not the devs that want this. It’s the damn client that keeps complaining about the “gravity” or the “momentum” or the “scroll speed” of the site. Locomotive.JS being the main thing clients want us to use… no amount of explanation of all your valid points will persuade them if “this one cool site we like had it”. I will say this… the scroll speed being different between Chrome, Safari and Firefox doesn’t help our cause… wish these were normalized at the very least so we can avoid “it feels better in X, but we use Y browser” notes. Allowing an easing function API for scroll would be a middle ground I could live with. It’s better than what we have now (a bunch of award winning sites emulating scroll with translates).
hnick 3y ago
Do you feel the same way about scroll-enabled menus? I had to implement a menu recently (similar to the one on https://getbootstrap.com/docs/5.3/getting-started/introduction/ https://getbootstrap.com/docs/5.3/getting-started/introducti...) and my first draft used traditional anchor-to-id links. It was very jarring and also felt weird being flush with the top - we added a jQuery smooth scroll to go to just a little above the item in a few hundred ms and it felt much better. I say this as someone who generally hates scrolljacking and custom scrollbar rendering on sites.
andrei_says_ 3y ago
In pay experience, scrolljacking happens after front end devs are told to implement it by the designers and the designers are told they must do it by the marketing people who in turn have been begged by both the front end devs and the UX team and. The design team to please record wider this insane decision - but insisted on it anyway. I have a collection of articles and studies and discussions on scrolljacking that I show to the business stakeholders when it comes up. I make sure thy hear from multiple parties independently when such an idea starts making its way toward implementation. But it is exhausting because trendy flashy websites still use the technique and do catch the eye and I have to explain why we can’t and should not have the shiny toy - despite big brand x y or x having it. In which process I am saying no to the very people deciding on my bonus. Just a bit of perspective.
Izkata 3y ago
> Front end devs, I implore you. Stop acting like you think you know what the user wants in regards to scrolling behavior. Smooth scrolling already exists natively in every browser. There's no need to try to re-implement it in JavaScript. Your implementation will not work in every browser, and will only cause strange stuttering, bouncing, or even end up somehow completely disabling scrolling altogether. Do not try to get fancy and implement "momentum" into scrolling. You're changing a well-understood behavior into something that is unexpected and jarring, and likely it won't work anyways. Smooth scrolling can cause motion sickness because it doesn't perfectly match up with the action. Javascript versions make it even worse because the ratio is pretty much guaranteed to be off from the user's normal scroll amount, particularly with a mouse or touchpad. It's not that bad for me, but I do disable it wherever possible because I find it disorienting. Can't do that with javascript implementations.

fsckboy 3y ago

> Do not impose your preference of 1 click ~= 1 line excuse me, but no designer ever gave audience to such a sensible suggestion

zimpenfish 3y ago

> And disabling zooming? I had a weird experience with Google Groups recently - I zoomed in because the text was too small and ... the page resized the viewport to its original pixel size even though the font was scaling. Ended up with about 10 characters in an unscrollable viewport. HILARIOUS.

aidenn0 3y ago
I had the opposite problem with a web page the other day. When I zoomed in, the text resized itself to still fit the same amount of text in the viewport, but since other elements would zoom correctly, the more I zoomed in, the smaller the text got.
- yencabulator 3y ago
  Yes, I see this paradoxical zoom behavior all the time. Alternate horror scenarios that are all too common: Zoom only to have one picture take over the whole page, pushing text off the side (not even down, off screen to the side). Zoom only to have the text immediately become wider than the screen, forcing you to scroll sideways for every single line.

paulddraper 3y ago

> And disabling zooming? WHO EVEN DECIDED THAT WEBSITES SHOULD BE ALLOWED TO DO THIS?! Applications such as maps, image editors, presentations, and flowcharts benefit from having control over zoom. (And you'll notice that almost every one of them does.) This of course is only one difference of many between "documents" and "applications" and the web is being used for both.

_jal 3y ago
Maps drive me fucking nuts, taking over zoom. As do nearly every other app that does it. They think they know what's good for me, and they don't, and it leads to me using them less. Yes, paper maps just work better for me a lot of the time. The only thing maps.app or Google maps are good for are finding places to spend money or driving to places to spend money. If you have any other spatial interests, they're almost pointless. I would happily run a build that removes this capability.
- paulddraper 3y ago
  I would love to see your maps app that doesn't touch zoom.
  - throwaway14356 3y ago
    No offense, I had to try that.. https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE_elevation.jpg https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE_el... Look how fast and responsive it is!
    - aendruk 3y ago
      With progressive decoding and spatial range requests this could actually be a reasonable replacement for a slippy map.
    - paulddraper 3y ago
      I'll use it on my drive home.

shadowgovt 3y ago

> The hijacking of scrolling pisses me off so god damn much that I've considered building Firefox from source and modifying the code to completely eliminate a website's ability to set the scroll position.[0] That'll break just about every cloud logging UI I'm aware of, but what you do to your own UA is your business.

kyleyeats 3y ago

You're mad at the wrong people here. I've never met a frontend dev who doesn't hate moving stuff vertically or scrolljacking. It's the marketing people that want it.

ncallaway 3y ago
The one that hurt me the most was making a page that started at the bottom and scrolled up. I left a comment somewhere in the JavaScript apologizing for it.
- eddd-ddde 3y ago
  I really want to know what was the reasoning they gave you to do that

depressedpanda 3y ago

> I'd pinch to zoom in...but some moron front-end dev has adopted the beyond-bone-headed mentality of "removing features is a feature!" and makes their site tell the browser to not allow zooming because...why? Someone please, tell me why. For sites that have no business disabling zoom: no idea, and it annoys me too. I just chalk it up to dev, designer and/or managment incompetence, close the tab and never return again. /Moron frontend dev

drewrbaker 3y ago

As the poor sap who’s had to build lots of these types of sites, I’ll tell you that it’s not the devs that want this. It’s the damn client that keeps complaining about the “gravity” or the “momentum” or the “scroll speed” of the site. Locomotive.JS being the main thing clients want us to use… no amount of explanation of all your valid points will persuade them if “this one cool site we like had it”. I will say this… the scroll speed being different between Chrome, Safari and Firefox doesn’t help our cause… wish these were normalized at the very least so we can avoid “it feels better in X, but we use Y browser” notes. Allowing an easing function API for scroll would be a middle ground I could live with. It’s better than what we have now (a bunch of award winning sites emulating scroll with translates).

hnick 3y ago

Do you feel the same way about scroll-enabled menus? I had to implement a menu recently (similar to the one on https://getbootstrap.com/docs/5.3/getting-started/introduction/ https://getbootstrap.com/docs/5.3/getting-started/introducti...) and my first draft used traditional anchor-to-id links. It was very jarring and also felt weird being flush with the top - we added a jQuery smooth scroll to go to just a little above the item in a few hundred ms and it felt much better. I say this as someone who generally hates scrolljacking and custom scrollbar rendering on sites.

andrei_says_ 3y ago

In pay experience, scrolljacking happens after front end devs are told to implement it by the designers and the designers are told they must do it by the marketing people who in turn have been begged by both the front end devs and the UX team and. The design team to please record wider this insane decision - but insisted on it anyway. I have a collection of articles and studies and discussions on scrolljacking that I show to the business stakeholders when it comes up. I make sure thy hear from multiple parties independently when such an idea starts making its way toward implementation. But it is exhausting because trendy flashy websites still use the technique and do catch the eye and I have to explain why we can’t and should not have the shiny toy - despite big brand x y or x having it. In which process I am saying no to the very people deciding on my bonus. Just a bit of perspective.

Izkata 3y ago

> Front end devs, I implore you. Stop acting like you think you know what the user wants in regards to scrolling behavior. Smooth scrolling already exists natively in every browser. There's no need to try to re-implement it in JavaScript. Your implementation will not work in every browser, and will only cause strange stuttering, bouncing, or even end up somehow completely disabling scrolling altogether. Do not try to get fancy and implement "momentum" into scrolling. You're changing a well-understood behavior into something that is unexpected and jarring, and likely it won't work anyways. Smooth scrolling can cause motion sickness because it doesn't perfectly match up with the action. Javascript versions make it even worse because the ratio is pretty much guaranteed to be off from the user's normal scroll amount, particularly with a mouse or touchpad. It's not that bad for me, but I do disable it wherever possible because I find it disorienting. Can't do that with javascript implementations.