-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Description
The sidebar nesting logic is inconsistent which can create challenges for plugin and theme authors looking to target specific navigation levels.
Here is the docsify HTML output from a three-level sidebar navigation:
<div class="sidebar-nav">
<ul>
<li class="active">
<a href="#/page">Page</a>
<ul class="app-sub-sidebar">
<li>
<a class="section-link" href="#/page?id=section">Section</a>
</li>
<li>
<ul class="children">
<li>
<a class="section-link" href="#/page?id=link">Link</a>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
Take notice of how the top-level item and its children are rendered:
<li class="active">
<a href="#/page">Page</a>
<ul class="app-sub-sidebar">
...
</ul>
</li>
The child items are rendered as a ul
element which is a sibling of the a
element. This makes it easy to target the ul
element via CSS (a + ul
) or JavaScript (aNode.nextSibling
).
Now take notice of how the second level links are rendered:
<li>
<a class="section-link" href="#/page?id=section">Section</a>
</li>
<li>
<ul class="children">
...
</ul>
</li>
Here the a
and ul
elements are contained in separate li
items. This makes it impossible to target the ul
from the a
element via CSS, and more expensive via JavaScript (aNode.parentNode.nextSibling.querySelector('ul.children')
). This also breaks the default list styling, as the sibling li
elements render as follows:
• Page
• Section
•
• Child
• Child
What I would hope to see is the same nesting logic applied to all levels of the sidebar navigation: links that have children are rendered as an a
tag immediately followed by a ul
tag containing the children:
<li>
<a class="section-link" href="#/page?id=section">Section</a>
<ul class="children">
...
</ul>
</li>
Using this nesting logic would make targeting via CSS and JS much easier, and allow the default list styling to work for an infinite number of levels:
• Level 1
• Level 2
• Level 3
• Level 4
...
Thanks!