Animate nav item and panel activation

[PaperStrike]

PR Checklist

• 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

• Bugfix.
• 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 6e60221.
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

   hexo-theme-next/source/css/_common/outline/sidebar/sidebar-nav.styl

   Line 49 in 7ead651

   --deactivate-duration: .3s;

   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

   hexo-theme-next/source/css/_common/outline/sidebar/sidebar-nav.styl

   Line 8 in 7ead651

   transition: height $transition-ease;

   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]

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

[stevenjoezhang]

I found that the following algorithm is not accurate

navChildHeight += (singleHeight * activateEle.childElementCount) + 5;

singleHeight is not reliable because of line wrap