deprecated-flexible-nav

deprecated-flexible-nav copied to clipboard

even with your demo-page, the last item(s) are never being focused (even when you click on these items), depending on the amount of contents below these items.

sorry, but I didn´t have the time to check the code yet.

It's because in the lib, "focusing" means having passed the related header. In other words, when a linked header is scroll down and rises above the page viewport, the "focus" move on to this header [EDIT].

In my demo, the last section called "Init" is too small to be passed if your window is high enough.

If you want to verify on the demo page, you can reduce your window very small in height and scroll down (BTW there will be some overlap in the flexible nav).

I havn't found better to compute the current focus from a scrollTop value. It matches most of cases. Tell me if you have a better algorithm in mind. Thanks.

that´s exactly what I´ve been thinking. but I don´t agree that it "matches most of cases" ... IMO it fails with most usecases. it only works if the last section is bigger than the viewport (which is most unlikely if you´re not having lots of contents). however, I´ll take a look at the algorithm. thanks for your answer.

I will try to make my explanation clear enough, despite my English :

When I mean it matches almost most of cases, it was about when you click on a nav link, the right link is focused (except for some ending items). If I would change the algorithm to have a different origin point (instead of the viewport top) this will probably not works anymore if I still only based on the current scrollTop. Because, with native #hash anchor links, when you click on a nav link, the related header goes on top of the page (and not in the middle for example). So my lib just relies on this native behavior, that choice browsers take to handle anchor links.

That's why, I don't find a better algorithm to handle both scrolling and nav link clicking. I mean if I kept the "scrollTop" and the "window height" as inputs of the algorithm. But I don't see better inputs just because we can't predict where people are currently reading (which section are they reading on the viewport?) except the viewport itself (the scrollTop level).

*and presuming the reading section is in the center will break the anchor link thing.

One way would be to "follow" the mouse position on the viewport but I find it a little counterintuitive and a little overkill for the issue.