Animate nav item and panel activation

[PaperStrike]

PR Checklist

• [x] The commit message follows guidelines for NexT.
• [ ] Tests for the changes was maked (for bug fixes / features).
  • [ ] Muse | Mist have been tested.
  • [ ] Pisces | Gemini have been tested.
• [ ] Docs in NexT website have been added / updated (for features).

PR Type

• [x] Bugfix.
• [x] Feature.
• [ ] Code style update (formatting, local variables).
• [ ] Refactoring (no functional changes, no api changes).
• [ ] Documentation.
• [ ] Translation.
• [ ] Other... Please describe:

What is the current behavior?

1. .active-current being set to the current active item's <a> child, not the item itself, which seems to be a mistake by https://github.com/next-theme/hexo-theme-next/commit/6e602213e7b1fb239cc5f177453025e0740ca5af.
2. Nav items being activate and deactivate without CSS transitions or animations.
3. Nav panels being activate and deactivate without CSS transitions or animations.

Issue resolved:

What is the new behavior?

1. Set .active-current to curent active .nav-item.
2. Use height and opacity CSS transitions during nav item activations and deactivations.
3. Use opacity, transform CSS transitions and height CSS animations during nav panel activations and deactivations.

• Link to demo site with this changes:
• Screenshots with this changes:

How to use?

In NexT _config.yml:

[coveralls]

Pull Request Test Coverage Report for Build 4209740912

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 97.614%

---

Totals
Change from base Build 4060926187:	0.0%
Covered Lines:	394
Relevant Lines:	399

---

💛 - Coveralls

[PaperStrike]

Here are two problems at least to discuss,

1. The panels' transition and animation duration. Currently it's 300ms, defined in https://github.com/next-theme/hexo-theme-next/blob/7ead651dcd62b2ca7bac475599259b7a24ad5b05/source/css/_common/outline/sidebar/sidebar-nav.styl#L49 Wondering if it's too fast and if it should be defined somewhere else to be controlled more easily.

2. .sidebar-nav transitions. Currently only its height has transitions with default durations, defined in https://github.com/next-theme/hexo-theme-next/blob/7ead651dcd62b2ca7bac475599259b7a24ad5b05/source/css/_common/outline/sidebar/sidebar-nav.styl#L8 Should the same opacity, transform transitions and durations as the panels' ones be used in .sidebar-nav?

[PaperStrike]

Convert to draft again to do some cleaning. You can still review this PR to suggest how the animations and transitions should be or if they shouldn't be used at all, and everything like that.

[PaperStrike]

I got my local dev env a mess and it's four months ago which worses the memory... so... I need some cleaning locally for some time. And any help on this is highly appreciated.

[ljcbaby]

要不先整理合并一部分？ How about merging the part we had?

[PaperStrike]

The panel container's transform animation of translateY(-20px) has to be split into relevant transitions of each panel mainly because animations run on on the page's initial load, which is not desired, while transitions don't.

The 20px of sidebar-nav padding bottom was moved to the padding top of .sidebar-panel-container, mainly because .sidebar-panel-container hides overflow contents while the inner panels have the above transform which overflows.

[PaperStrike]

Here's a problem: When switching between pages with and without TOC, the height of .sidebar-nav changes from/to 0. If we keep the 20px transform (as of current commit https://github.com/PaperStrike/hexo-theme-next/commit/2aa06f1c55418f8e7483e78010dab0021b5e57ca), the leaving panel will have a conspicuous Y movement. What's worse, when we switch from a TOC-activated page to a no-TOC page, the overview panel has a visual clip on its move from -20px to 0, as there's no padding at the time it moves,

Case 0 GIF

An intuitive solution would be to disable the 20px transform on such cases, which results in:

Case 1 GIF

Well, for the activating panel it will disable all the visual movements and only left opacity changes. So we can futher delay the padding changes to retain some movements of the activating panel, which results in:

Case 2 GIF

The panel height will change two times. We can disable the above delay on a specific panel, so that one panel has movement+opacity changes, another has only opacity changes, (don't forget that we are only talking about the TOC-with-without cases, in normal cases we always have movement+opacity changes for both panels.) which could be:

Case 3 GIF

Case 4 GIF

From 0 to 4, which one do you prefer? Do you have a better suggestion? Thank you.

[PaperStrike]

After reviewing the above cases, I found that case 1+ are all disabling the 20px transform when switching between pages with TOC and pages without TOC, and case 2+ are all trying to use delayed padding transitions to workaround the cases that the disablement can't cover.

case 5 Maybe I think too much. Disabling the 20px transform only when switching from pages with TOC to pages without TOC may have resolved all the disharmonies.

Will commit within 24h.

[PaperStrike]

Case 5 implementation will have a confusing CSS rule that is used to fix the "conspicuous movement" I mentioned in case 0. However, it looks not so "conspicuous" in the GIF I attached. To have a clearer view, I captured the highest position the TOC can get in case 4.5(case 5 without handling the above move) and in case 5.

case	original	sharpened	in action
4.5
5

[PaperStrike]

When switching from a page with TOC to a page without TOC, the TOC is retained to prevent flash and to preserve the visual animation effects. The retained TOC is marked .placeholder-toc to help differentiate. However, this may break some user/third party scripts as they don't have such distinction. If we remove the .post-toc class and apply the same style to .placeholder-toc, the user may see an unexpected TOC panel in these cases, as they may have some custom stylesheets applied only to .post-toc. In any case, keeping the TOC for some time after the page switch, even if we remove it as soon as its animation is finished, is somewhat breaking.

Aside from not keeping the animation effect, we can also delay the completion of the TOC switch on such page switches. That is, wait for the TOC transition to finish (currently 300ms), and then switch the other parts of the page.

Should we drop the retention or wait for the TOC transition in those cases?

[PaperStrike]

If you have any suggestion, feel free to edit this PR branch directly or ask me to change. Thank you.

Here are at least two problems to discuss,

1. The panels' transition and animation duration.

Now aligned with the other CSS transition durations (200ms) by using a new stylus variable $transition-duration.

2. .sidebar-nav transitions.

Now it has height, color, and border-bottom-color transitions.

There's one last placeholder TOC problem mentioned above.

[stevenjoezhang]

It looks perfect! For some issues to be discussed, I suggest to merge it first and then see the feedback from users