Smooth scroll + active link glitch

I’ll make this as short and clear as possible.

I’m on the final project for responsive web design. I’ve added smooth scroll to hash links and also an active class for the nav links using javascript.

It basically works fine, but the last link doesn’t scroll to the very top of it’s corresponding section, but rather around a pixel before the top (see image). This is very annoying because it causes the last link not to become active and change color, unless you manually scroll down.

Can anyone explain this behaviour to me and if there are any clean workarounds or fixes?

I’ve found one fix, which is making the previous section have a fixed height, but this isn’t as clean since I would rather the contents and padding determine it’s height rather than have to use fixed heights and media queries to bypass this glitch.

here is the link to the project

Normally you want to switch active link slightly before your section hits the top. You have to agree that if 75% of the viewport is taken by “Contacts” section then it’s more about contact section rather than previous, right? Try:

$(this).position().top <= scrollDistance + 200

That makes all the sense in the world, thank you for that solution is brilliant and it works perfectly in this type of situation.

I just have one question remaining though, I just want to know so I can have a deeper understanding.

Was the issue I encountered, where the smooth scroll would stop a pixel or so before the section (rather than exactly the top of the section) - if the section had no fixed px, vh or % height - a normal behaviour or bug, or is there something else going on?

My guess would be that this is some sort of a rounding issue, when scroll movements rounded to a pixel while boxes are rendered with greater precision, so you might have position.top === 100.025 while scroll === 100

…so if you want to trigger perfectly at the top you need Math.round(position.top)

That would make sense, but after reading your response I did some testing and as long as height is specified, and not “height: auto;” ,the scroll does not round to a pixel, it stops exactly where it should, even if the height is let’s say “height: 100vh”, which would result in non rounded distances.

So you’re absolutely right that the scroll movement is rounded, but not always, it only gets rounded if height isn’t specified…which is weird to me, I would wonder if there’s a way to get around this with “height:auto”?

This probably seems like a non-issue in this case, but it would be an issue if each section had a different bg colour, because you’d see a small line from the previous sections colour at the top of the screen if you clicked to smooth scroll to a section with “height: auto;”

Any ideas or is this just a dead end?

I was wrong: “height: 100vh” or “height: 100%” does not result in heights with decimal places, apparently they automatically get rounded.

So summed up the problem is that the section with “height: auto” does result in a height decimal places, yet the anchor link positions you at a rounded number by default. And the section with “height: auto” has decimal places because it contains a css grid gallery with images, and the images have heights with decimal places.

So in the end the question would be, how can I make the section with “height: auto” have a height that has no decimal places? Is there a way to make the height of images within the css grid rounded, or to make the section adjust for that somehow?

OK, final update.

The problem wasn’t solely that the section was “height: auto”, but rather it was a combination of that and the fact that I was using irregularly sized images for the gallery. I changed the images out for placeholders with standard sizes and the bug stopped occurring instantly.

After that change, if you click the link to the third section if will place you exactly at the top of the section, rather than a pixel above that (like in the screenshot I provided).

I really have no clue why having irregularly sized images would generate this small bug, I can only guess, but there it is. What I learnt from this is to always optimise and standardise image sizes.

I hope this thread helps somebody some day and thankyou to iiiked for trying to help me out, the javascript tip you gave me, although it didn’t solve my initial issue, was very interesting regardless and I will without a doubt use it.