CSS adjustments for unordered list outlines

Feature Requests
,
1

This is tangential to the discussion about the Changes to Knowledge Base. I was going to leave it there, but an additional request came to mind that made me choose to just make a new topic.

  1. I’d like to suggest the following CSS adjustments that would remove the list style (i.e., bullets) from unordered lists that are displayed according to Notenik’s {:outline-bullets} command and push the list style for the summary element aside so the list item’s with nested lists are inline with the one’s that don’t have them.

    If you notice, the table of contents for the web version of the Knowledge Base are misaligned. These changes should straighten things out, if you’re interested, and may also improve the appearance of ul outlines for the default note display when{:outline-bullets} is used.

    .outline-ul-within-details {
    list-style: none;
}

details > summary:first-of-type {
    list-style-position: outside;
}

  2. Additionally, I’d like to request for style parity between unordered list outlines that appear as part of a table of contents and elsewhere.

    From the looks of it, when an unordered list outline appears in a table of contents then entries without children do not have the summary element list style (the arrows) appear beside the main ul element list style (the bullet).

    An abbreviated sample from the web KB:

    <ul class="outline-ul-within-details">
<li class="outline-li-bullet">A. <a href="knowledge-base-overview.html" class="nav-link">Knowledge Base Overview</a></li>
<li>
<details>
<summary>
B. <a href="knowledge-base-navigation.html" class="nav-link">Knowledge Base Navigation</a></summary>
<ul class="outline-ul-within-details">
<li class="outline-li-bullet">1. <a href="backwards-and-forwards.html" class="nav-link">Backwards and Forwards</a></li>
<li class="outline-li-bullet">2. <a href="up-and-down-the-hierarchy.html" class="nav-link">Up and Down the Hierarchy</a></li>
<li class="outline-li-bullet">3. <a href="search-the-knowledge-base.html" 
</ul>
</details>
</li>
</ul>

    And a sample as it appears in Notenik’s default display:

    <ul class="outline-list">
<li>
<details class="list-item-1-details">
<summary>List item one </summary>
</details>
</li>
<li>
<details class="list-item-1-details">
<summary>List item two </summary>
</details>
</li>
<li>
<details class="list-item-1-details">
<summary>Just another one </summary>
<ul class="outline-list">
<li>
<details class="list-item-2-details">
<summary>With children </summary>
</details>
</li>
</ul>
</details>
</li>
</ul>

    As it stands, in a table of contents it looks like only list items with nested ul elements are wrapped in a details tag. Childless list items aren’t, so they don’t have an additional arrow next to them like list items that do.

    It looks like non-TOC unordered list outlines do get wrapped in a details tag irrespective of whether they have children.

    From what I understand, each outline is generated using separate functions that format their corresponding ul elements different from the other. Is it possible that they may be able to be structured and styled similarly?

The length of this request belies its overall impact on the software, despite its aesthetic intrigue.

But if you have the opportunity to test out and are swayed by the CSS adjustments, you may find that it lends the second request some muscle and take the whole into consideration according to how you gauge its necessity.

:canoe:

2

@ThePrinter Thanks for the suggestions! I’ve implemented #1 in the latest beta. Try it out and let me know what you think. You can also see it in the web version here.

I’ve also adjusted the spacing between items so that that is more uniform.

Haven’t considered #2 yet. I’ll take a look at that next.

Thanks again!

1 Like
3

In general, I prefer the way the table of contents is displayed, in that you don’t have to click on an arrow just to find out that nothing is revealed. (Sorry, couldn’t resist the Dylan link.)

However, since the table of contents is formed based on the contents of the collection, I can use more sophisticated code to “look ahead” to see if there are any children, before deciding how to format the preceding note in the outline. On the other hand, when creating a non-TOC unordered list outline, I’m just processing line by line, character by character, so a similar sort of “look ahead” function would be more difficult, and more expensive (in terms of processing time).

So that’s why the two are different.

4

Understood, that makes a lot of sense. I appreciate the explanation.