Increase Sensitivity of Scroll Snapping in Google Chrome - html

I have implemented a design for my website using scroll snapping via scroll-snap-align documented here and scroll-snap-type documented here.
The implementation works, however on Google Chrome the user must scroll quite "firmly" in order to move to the next section. On the other hand only one "tick" of the scroll wheel is required to move to the next section on Firefox. The behaviour on Firefox is much more desirable whereas the Chrome behaviour feels clunky and unnatural.
I'm wondering if there is a way to adjust the scroll sensitivity on Chrome or something along those lines in order to achieve the same behaviour that is present in Firefox.
I have created a JSFiddle with a minimal implementation that demonstrates the different behaviour across the aforementioned browsers.
Thanks in advance.
EDIT: The behaviour in the JSFiddle (and indeed on my website) has now changed to something different but equally unsatisfactory. Now scrolling down one "notch" on the mousewheel causes the scroll snap to go 2 sections down instead of 1, I have created a new JSFiddle with a 4th section to confirm that the scrolling goes down 2 sections and not straight to the final section. I have been unable to find a reference to the update or change in specification that caused this.

I ran into the same issue described above and so I turned to https://lucafalasco.github.io/scroll-snap/. I've personally tested it on Chrome and Firefox and it seems to work well - that is to say, scrolling with the mouse wheel does not skip sections. I'm not intending to support IE11 so this serves my purpose.

Related

How can I apply “inertia” style horizontal scrolling to a div?

I have successfully implemented horizontal scrolling on wikiprop.org but the example I followed has this inertia/momentum effect, where you can swipe and it’ll continue scrolling and gradually slow down—as is common across the web.
Why doesn’t my horizontal scroll do the same? On my machine, at least, the scroll feels “sticky” meaning it doesn’t continue scrolling to a gradual stop when I do the “fast swipe” gesture.
Much appreciate any support, and please let me know if this is not clear enough.
I looked at your site in Chrome with the developer tools opened. If you look at the following screenshot, you'll see that Chrome is only rendering some of the CSS. It appears you wrote your styles using SCSS and an error occurred in the pre-processing step. Since browsers can't read SCSS, you can imagine all the possible issues that might arise.

Chrome Resizing Navigation Menus

So my problem is that for some reason on one page of a website I've been fiddling with, the two navigation bars that I have (Top and Sidebar Navigation) are for no apparent reason scaled down in the Google Chrome browser, their behavior is entirely normal in both iE and Firefox. The bar's remain completely functional, but are simply scaled down perhaps to 66% of the intended size.
Here is the code for the page in question: http://pastebin.com/uvrPR1JW
Here is the code for a similar, but functioning page for reference: http://pastebin.com/5dAMREfC
They're running off the same style sheet so the issue is likely in the HTML, however the style sheet is linked in the comment section for reference. If anyone spots any reason why it would be doing anything like this it'd be great to know. And I apologize for the messy code, as I said I'm just playing around with it.
Update:
You may notice that my code includes at least one flexbox, here is question posted by another user that may be related but I can't make heads or tails of it: Chrome shrinks figure elements as they are added to a flexbox
Update: Doesn't seem to be a problem with the flexbox, the issue still exists even when I remove all content except the top header.
I'd say it's the setup of your navbar, how you have an image and you just change the position of it on hover. Chrome has a weird feature where it moves things around when there is images so I would suggest looking up how to make a proper navigation bar (It's pretty easy).

jsfiddle layout broken: wrong input size. Where is the size stored?

I came across a weird bug with jsfiddle. The layout I get when I visit the site is completely broken. This bug happened when I dragged the vertical resize bar while my second display disconnected. See this the result:
There is probably a way I can get this fixed from the inspector by resizing it manually, locating left panels and changing their width manually and than playing with the vertical resize bar; I'l keep investigating.
Where are the layout positions stored?
Before asking this question, I tried to reset my cookies, I had a look into local storage and session storage (they were both empty). I know it's a local issue because jsfiddle is too awesome to break like that, it's not because of the code in the fiddle, I opened the fiddle in private navigation and worked like a charm.
Edit: I fixed my issue by deleting .column.left, #handler_vertical appeared, I moved it and now data is fixed, but I still don't know where this is stored ;)
I had this same issue and worked out that it was after I reduced the size of my browser window, I'd accidentally moved the vertical bar left, which caused this to 'disappear', so when I resized the window to full, no vertical bar!
To fix, I searched the inspector element for 'handler_vertical', and around this were column left and column right, with widths set inline. Simply remove these inline widths and it's back to normal.
Strange that some js is still adding itself even after clearing cache and cookies!!
I accidentally deleted an HTML node in Chrome's inspector, which broke JSfiddle's layout.
When I reloaded the page, I was surprised to see the layout was still broken.
I cleared my cache and made a hard reload, but JSfiddle's layout was still broken!
The solution came out recently : I changed Chrome's theme... and it fixed JSfiddle.
Sometimes you just don't want to understand.
I know this was solved a while ago, but I just wanted to add that the FAQ acknoledges this and pasting Layout.setWindowSizes(null)into the browser console fixes the layout.
Source: http://doc.jsfiddle.net/faq.html
Same just happened to me, reloading the site had no effect but deleting last cached elements made it

Chrome 27: Fixed Element Leaves Artifacts Behind After JQuery Animation

I have run into a really weird bug. I have an element that the background colors drops off of until you take your cursor and select it.
Here is the page:
http://austinpray.com/test
Here is a video:
https://www.dropbox.com/s/t1f7fnvxslebjwj/2013-05-16%2016.33.21.mov
The video is taken with an iPhone because the issue does not occur when I am using a screen recorder oddly enough. It only happens inside of chrome. I have tried both chrome and a blank install of chromium will all caches cleared and such and this still occurs.
What am I missing? I will update as I do more testing on different devices.
EDIT (05/22/2013):
I did some more research and I found the following behavior:
https://www.dropbox.com/s/7tdz41l89qttmnx/2013-05-22%2017.20.20.mov
The problem seems to arise when animation and scrolling happen at the same time.
I froze the entire site with the issue here: mirror
EDIT:
Example
Here is a stripped down version of my code that actually works:
DEMO
The issue is not present in this one. What is different about the following demo and the code that is causing the issue? I have tried stripping out the parallax background code and that does nothing to fix the issue. I am currently rewriting the entire menu's css to see if I missed something simple.
temporary workaround
After learning a TON about how chrome renders elements (especially fixed elements) I came across this temporary solution:
-webkit-transform: translateZ(0);
I added this to my nav bar's style. This is basically a quirky little hack that does nothing to the page and turns on GPU acceleration. This will have to do for now either until chrome is updated or until I rewrite the entire menu bar functionality. The only downside is that resizing the window suffers a performance hit.
a more elegant solution
After all this research and troubleshooting I figured out that the only real problem is that chrome needs to redraw the element all the way rather than stop at an arbitrary point and leave artifacts. Since the pure CSS solution creates some performance issues I I found an excellent method of forcing the browser to redraw an element via jQuery!
$.fn.redraw = function(){
$(this).each(function(){
var redraw = this.offsetHeight;
});
};
I'm using this on the deployed page and it seems to be working great with no performance hits. I'll keep it around as long as chrome 27 is still floating around.
I also found weird behavior and possibly the root of the problem:
The issue does not occur when I have Compositing for fixed position elements enabled in the chrome about:flags section (chrome://flags/). I am running Chrome Version 27.0.1453.93.
My issue is somehow connected with how chrome handles the stacking context of fixed elements and animating fixed elements as the browser scrolls. This article expands a bit on the changes.
How Chrome handles compositing
GPU acceleration as it related to compositing
As this answer showed up first when searching for this issue I thought it would be helpful to link to another answer that seemed to resolve the problem more fully.
https://stackoverflow.com/a/12023155/2192201
And if you don't feel like clicking through, all that was needed to prevent the artifacts while animating was this one line of css:
-webkit-backface-visibility: hidden

Prevent Chrome from setting scrollbar position to last on history state change

I used https://github.com/browserstate/history.js in a recent project to manage state changes in an ajax rich website.
Chrome exhibits a very annoying behaviour at times where it decides to reposition the scrollbar to some arbitrary position after a state change event. I have not experienced this problem with any other browser.
Does anyone have any suggestions? I would post code, but am not sure which parts will be relevant and I am hoping there is an obvious solution to this problem.
There are some obvious workarounds. Scroll to the top if that's what you want, or add a field to data object to store scroll position and restore it yourself. If it's a Chrome bug, work around it; if it's a feature you don't like, work around it; and if it's something you just have to implement yourself with three lines of code, work around it.