Allow folding draft chapters with children by interacting with their names

[ISSOtm]

This PR allows links to draft chapters that have children elements to function like the "arrow" to toggle collapsing children items when clicked. This includes styling them as "real" links to highlight their interactivity, and turning the arrow when clicked.

This has been requested by some of my readers for the "Graphics" link in https://eldred.fr/gb-asm-tutorial.

This is implemented by outputting links with the toggle class instead of divs for chapters fulfilling the aforementioned criteria, removing the styling and adding the toggle functionality.

I did not add any documentation, as this is purely a UI change, and this part of the UI is not documented anywhere in the first place.

[schungx]

I solve this problem with a custom CSS:

.chapter li {
    color: inherit;
}

Of course, that also means that there are no more "disabled" chapters as they'll all render as content-less headers.

[ISSOtm]

This change is not about presentation as much as functionality: "disabled" chapters that have folded children can be clicked on, and doing so expands the list. Since they then have functionality, they are not styled as "disabled" anymore, but that's not the main focus of the PR.

[ISSOtm]

Bump

[ehuss]

@ISSOtm Can you provide a more detailed description of what this does, how this works, what it looks like, and what the use case is?

Also, this will need:

• Documentation
• A test of some kind
• Update the test_book with an example of what this does.

[ISSOtm]

I updated the OP regarding the description and documentation; I'll update the test book when I get back near a computer.

As for a test, I'm not sure what could and should be tested.

[ISSOtm]

Rebased, and pushed the addition to test_book (oops).

[ehuss]

I'm concerned that this stretches the draft chapters beyond what the intended behavior is. I think people will abuse this to implement non-chapter organization (that is, not using them as drafts at all). Not only could that be confusing from a UX standpoint, but also things are broken in that situation (such as next/prev navigation).

If your only intent is to make the parent draft titles clickable, I think that's fine to do as long as it retains the draft styling.

[schungx]

I think people will abuse this to implement non-chapter organization

Incidentally, this is exactly what I plan to use it for... because this type of functionality is not available otherwise.

[ISSOtm]

I find your concern valid, but I must also second @schungx: this is a functionality that is otherwise lacking, and exactly the use case that I am aiming to fill. (See the "Graphics" group here for an example.)

An alternative would be to allow non-link list items in the SUMMARY.md (and probably error out if they don't have any children), and transfer this functionality to them.

[ehuss]

Ah. In that case, I think something like this should probably go through more of a design process before progressing with a PR.

I think to move forward with something like this, there will need to be quite a bit more investment to figure out the right design. Some ideas of things to investigate:

• How do other documentation tools with a navigation sidebar or TOC handle sections or chapters without content?
• Semantically what is a better way to represent these kinds of non-content chapters? I think calling them "draft" does not correctly match the new behavior.
• What should the syntax be in SUMMARY to differentiate draft chapters from non-content entries?
• What will it take to make sure everything is functional? What besides next/prev is broken?

[ehuss]

I'm going to close in favor of discussing a proposed change in #1340. Thanks!