Late last night, I launched a rewrite of our front end HTML and CSS that is designed to look nearly identical, but is much faster and designed to be more easily updatable and manageable moving forward.
Let me know if you spot any bugs or inconsistencies.
Jump to PostWell, right off the bat I see you have eliminated the "page skips while scrolling" problem, so congrats on that.
Jump to PostI hit the "sweet spot" once on the old code. The display couldn't decide whether to skip down, or not so it just rapidly oscillated. A little disorienting. Had a similar effect on me as
Jump to PostHmmm. I tried twice to insert a picture but it failed both times. No error message. It just didn't post.
Jump to PostOK. Here it is.
Jump to PostI get the same "my eyes have gone funny" feeling from that picture that I got when the page was fluttering. My brain kept trying to "fix" what I was looking at (and failing).
Maybe it's just me.
Well, right off the bat I see you have eliminated the "page skips while scrolling" problem, so congrats on that.
That was a feature, not a bug :-p
I hit the "sweet spot" once on the old code. The display couldn't decide whether to skip down, or not so it just rapidly oscillated. A little disorienting. Had a similar effect on me as
Hmmm. I tried twice to insert a picture but it failed both times. No error message. It just didn't post.
Here's a pic of me!
Oh, gotcha!! :) Will fix in a few mins. Just wrapping something up first :)
This should work now :)
OK. Here it is.
I'm confused what I'm looking at.
I get the same "my eyes have gone funny" feeling from that picture that I got when the page was fluttering. My brain kept trying to "fix" what I was looking at (and failing).
Maybe it's just me.
Sorry about that! It was meant to be a feature and I never realized it was causing so many problems.
I sure hope the current behavior is a bug and not by design. When I click on the 2 hour ago of a latest reply I see it start at the top and scroll all the way to bottom.
That's horrible.
Umm ... isn't that the way it's always been? When you click on the thread title or the timestamp of the first post in thread, it takes you to the beginning of the thread. When you click on the reply counter or the timestamp of the last post in the thread, it jumps to the bottom. It's been this way for 20 years?
Is the undesired behavior that it doesn't jump straight to the bottom but it does the animation thing?
No. In the past it would jump to the 2 hour ago reply. As it is, this is a horrible effect and if it stays will mean some will leave due to poor design choices.
Let me make it simple. It's awful.
I am thoroughly confused because I didn't change anything at all having to do with this, I promise. If something did change, then it's a bug.
It would jump to the 2 hr ago reply? Why would it jump to a random post in the middle of the thread?
Can you please explain what 2 hr ago reply you're talking about? I see 1 hr ago, and I see 4 hrs ago. Obviously 2 hrs ago is relative time, relative to when you loaded the page. Which post are you referring to? Your expectation is it would jump to a random post in the middle of the thread?
I haven't changed anything (knowingly) regarding this?
I just checked the Github repo from December, before this latest wave of changes, to see if I was doing anything different.
Back then, when you click on the reply count, it jumped to the last post in the thread. Today, it still jumps to the last post in the thread. I'm confused by what you're referring to?
I was using an example. If the post is 16 hours old and the last reply is 2 hours ago, I click on the 2 hours link and the page opens and it SCROLLS down to the 2 hour old discussion. This is in Opera, Chrome but works fine (jumps to 2 hour old post) in FireFox.
As to which post, it's ALL posts with enough replies.
So a few posts up, I wrote:
Is the undesired behavior that it doesn't jump straight to the bottom but it does the animation thing?
But you responded no, that's not the problem. So the problem ISN'T that it animtates the scroll instead of jumping straight to the bottom?
To me, scrolling is not animation. Odd that Firefox jumps to the reply, but Opera and Chrome scrolls to the reply.
Oh, it's animation in the sense that it's a javascript animate() function that literally animates the scroll down browser event. I'll fix it.
https://developer.mozilla.org/en-US/docs/Web/API/Window/scrollTo
Notice the parameter behavior:
Specifies whether the scrolling should animate smoothly (smooth), or happen instantly in a single jump (auto, the default value).
That's why I think of it as animating.
But, yeah, I'm actually at a loss here because I'm not passing in the behavior parameter so it should be doing the default?
OK, so I confirmed my code is using the default browser behavior. Is it possible you updated your browser recently? I'm grasping at straws here, but is it possible that Chrome and Opera have the default browser behavior to use animated scrolling and that Firefox does not?
Oh, it's animation in the sense that it's a javascript animate() function that literally animates the scroll down browser event. I'll fix it.
Sorry, was thinking about a different place in the code. This code just uses: window.scrollTo(x, y);.
OK, did some more research and found the CSS property scroll-behavior: smooth (which our framework uses) forces animated scrolling. I'd have to come up with a wonky workaround.
I noticed that there's no animated scrolling from my phone, so I did some more research, and it appears to be browser's choice how to implement the CSS scroll-behavior property.
OK, so a little more background. The big CSS project that just launched migrated us onto the latest version of Bootstrap, among other things that increased page speed dramatically and cut back our CSS and Javascript files by 50%. Apparently the latest version of Bootstrap embraces smooth scrolling, a CSS directive that different web browsers each implement different ways.
Apparently it's a love it or hate it thing that lots of people in the UX world are talking about. It's designed to keep you oriented as to where you are on the page, and it seems to be a feature that even some big sites are slowly migrating to. Wikipedia conidered adopting it, but decided not to because it's web browser's choice how long the animation lasts for, and it can be frustratingly long on very long webpages. Some other big sites adopted it, and then users hated it, so they reverted back. The CSS framework we're using, and have been using for the past decade or more, (Twitter Bootstrap) seems to fully embrace it, so I'm going to read up some more about it.
OK, some more research done. It seems that UX experts recommend letting browsers decide how to apply smooth scrolling. Firefox decides to implement it when it thinks it is beneficial to the end user (depending on length of page, etc. I guess?), which is why it wasn't as noticeable. On Chrome, you can change the smooth scrolling setting here: chrome://flags/#smooth-scrolling
This is a change in how it worked before. Why is not so much a mystery now but your site would be the only site I would change the setting from stock for.
The default behavior in Chrome and Opera is awful on Daniweb. Again it's the only site I've seen this happen on.
I see no good reason to animate/scroll. The visual effect is horrible to say the least.
PS. chrome://flags/#smooth-scrolling does fix it but why is this up to us to fix your site behavior?
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.