> 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.
> 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.
No, they benefit from overriding the pinch gesture or the scroll wheel. Browser zoom shouldn't need to be a casualty for those features to work, it ought to stay available in some form.
Yes it can be, with the viewport meta tag. I've also seen some web apps, mostly maps, whose CSS or JS tries to resist browser zoom in ways that break the layout or make them unusable.
Plus, overriding the zoom gestures makes it really hard in mobile browsers to access the actual browser zoom, although I blame that on browsers.
yes you're right. we have a map with a toolbar at the top of the screen. when zoom was enabled people were constantly zooming in preventing them from being able to see some or all of the buttons hindering their ability to use the app. and causing confusion because they didn't realize they were zoomed in. as soon as we disabled zoom the complaints and questions stopped.
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.
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.
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.
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.
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.
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).
> 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.
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.
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.
> 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.
> 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.
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.