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!