On components page, nav shouldn't reflect state unless it updates as you scroll
On the UI components page the left nav will indicate the last link pressed and navigate within the page to the appropriate section. However, as you scroll the page, you pass through other sections, which means the left nav state doesn't reflect where you are in the doc. I think this would be more useable if we either:
- Did not make the left nav indicate navigation within the document
- Made the left nav update as you scroll through sections (AMP bind?)
Agreed that until we have scroll-bound CSS this is a little awkward
@spacedino for thoughts and design (we could remove the underline entirely—or make it appear then animate away after a certain amount of time, though that might just be distracting...)
when will we have scroll bound CSS?
and / or how hard is it to do AMP bind?
Not clear how long a general framework for scroll-bound CSS will take (probably early Q3, but maybe earlier/later WDYT @aghassemi ? ). Wouldn't be possible with amp-bind, because it's not linked to scroll.
I am thinking exposing "visibility" events on all elements and then using amp-bind to react to those events is the right way to handle this. This is more tied to visibility than scrolling (e.g. flipping from portrait to landscape does not scroll but does change visibility)
@dvoytenko What do you think about exposing something like on="enterviewport:<action>", on="exitviewport:<action> on all elements?
@choumx
@aghassemi that sounds promising! (and I stand corrected on the potential interaction between bind and scroll) Though I think we'd need to develop a system to prevent abuse (for instance, scrolling a little bit toggles a pop-up ad that blocks content)
@ericlindley-g Another option (which I actually like the best) is for us to handle this as a first-class feature. Specially considering the the smooth .focus() we also want to support and this can be merged into a single component. Allowing us to handle this means we can be smarter about it as well. For instance if on a larger screen, there are 3 headings displayed that correspond to items in the navbar, which navbar item should be highlighted? The correct answer is "whichever heading the user is looking at", which obviously we can't know but can guess and the more information we have the better the guess will be (for instance the scroll direction would matter it making this guess)
<script ... amp-focus.js/>
<amp-focus scrollspy-on-target use-smooth-scrolling>
<a href="#intro" ...
<a href="#content" ...
<a href="#summary" ...
</amp-focus>
use-smooth-scrolling and scrollspy-on-target are independent of each other and can be used on their own.
use-smooth-scrolling causes the jump to #target to be a smooth scrolling effect.
scrollspy-on-target causes the <a> to gain an active attribute when the #target is in the view. Only one item in amp-focus can be active at a time and we resolve conflicts and decide which one when multiple targets are in viewport.
If this approach sounds reasonable, I can bring it up in the next review meeting.