Page MenuHomePhabricator

[ToC] Enumeration of sections in the new ToC (numbers for ToC items)
Open, MediumPublicFeature

Assigned To
None
Authored By
Nux
May 1 2022, 10:33 PM
Referenced Files
F36993090: obraz.png
May 11 2023, 7:37 PM
F35872182: obraz.png
Dec 17 2022, 8:46 PM
F35871792: obraz.png
Dec 17 2022, 8:46 PM
F35861889: toc section hovering.webm
Dec 13 2022, 5:54 PM
F35861882: Screen Shot 2022-12-13 at 12.44.57 PM.png
Dec 13 2022, 5:54 PM
F35842580: Screen Shot 2022-12-06 at 4.35.48 PM.png
Dec 6 2022, 9:42 PM
F35842578: Screen Shot 2022-12-06 at 4.36.11 PM.png
Dec 6 2022, 9:42 PM
F35120931: obraz.png
May 9 2022, 5:06 PM
Tokens
"Love" token, awarded by Jules78120.

Description

Feature summary (what you would like to be able to do and where):

Add enumeration for the new ToC.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

A few users on Polish Wikipedia discord asked for this. They asked for enumeration specifically (like in the old ToC).

Benefits (why should this be implemented?):

I think this would make sections more obvious (where each item starts and ends). Currently its more like a wall of text.

Levels would be more obvious as well. Especially after T306562 which changes all of the items to the same color.

Prototype
Example article: https://pl.wikipedia.org/wiki/Jerzy_Skolimowski

Screen:

obraz.png (1×1 px, 332 KB)

Stylus export:
(note that you will need to adjust for change in T306562; especially font-size)

@-moz-document domain("pl.wikipedia.org") {
#mw-panel-toc ul {
    /* reset at the start of each level */
    counter-reset: tocsection;
    list-style-type: none;
}
#mw-panel-toc li::before {
    counter-increment: tocsection;
    /* combine values of each level with a period */
    content: counters(tocsection, ".") ". ";
    
    float: left;
    font-size: 0.875em;
    display: block;
    padding-top: 4px;
    padding-right: .3em;
}

/* modify first link (top link) */
/*
#mw-panel-toc > ul {
    counter-reset: tocsection -1;
}
*/
#mw-panel-toc > ul > li:first-of-type::before {
    display:none;
}

/* colors */
#mw-panel-toc ul a {
    color: #0645ad;
}

/* adjust widths */
.sidebar-toc {
    /* width: 15.25em; */
    width: 19.25em;
}
.mw-page-container {
    /* max-width: 94.625em; */
    max-width: 98.625em;
}

}

Event Timeline

The preference was removed in T284921: Remove "auto-number headings" preference (see the previous discussion and reasoning) and there don't seem to be new and different arguments in this ticket. Declining.

This is not the same. T284921 says:

The "auto-number headings" controls whether section numbers are shown in section headings. The default behavior is to show numbering in the table of contents, but not in the actual section headings.
Solution:
If there is no great demand for this feature, we should simply remove it. If the feature is to be kept, it should be implemented in CSS: the numbering would always be generated, but the browser would be instructed to not display them. Appropriate CSS rules for showing the numbers could easily be generated from the user settings on the fly. Numbering in ToC would remain

Also note that ToC is enumerated in legacy vector. When you create a new account you get this view:

obraz.png (835×397 px, 52 KB)

But with new vector and new ToC enumeration is gone. Not just from headings. From the ToC itself, not from headings.

obraz.png (345×244 px, 8 KB)

Also note that T284921 talks about numbers in HTML and a lot of users says that probably the numbers should be kept for headers but implemented with CSS.

Fairly similar CSS code can be used both for ToC (current function) and headers (old function).

@Nux thanks for raising this topic. Some thoughts:

  • Because the table of contents is now located on the side of the article there is less horizontal space available for it
  • The numbers on the section headings take up space, especially for h4s and beyond (for example 1.3.1, 1.3.1.1), so there's a tradeoff here — they might make the section headings easier to distinguish from each other, but they will for sure make the table of contents more difficult to read in other ways, and take up more vertical space, because there will be more line wrapping
  • Aside from possibly helping people distinguish one section from another (which is not necessarily the case, just a guess from some people thus far), there don't seem to be other benefits
  • I, and other members of the design team, think that the numbers add clutter/visual noise to the page with no clear benefit. In particular I think the numbers with decimal points are distracting.
  • It is quite easy to display the numbers with a few lines of CSS. I encourage you and others to do this, spend a few weeks with the numbers, then return with additional thoughts
.sidebar-toc .sidebar-toc-numb {
    display: initial;
    color: black;
    margin-right: 8px;
}
Screen Shot 2022-12-06 at 4.36.11 PM.png (849×598 px, 336 KB)
Screen Shot 2022-12-06 at 4.35.48 PM.png (846×559 px, 311 KB)

@alexhollender_WMF I mostly agree with what you wrote... just not with the final conclusions :). I see order in these numbers and the table of contents is generally more readable for me personally. I've been using this version for a few months now and have had no problems with readability.

Please note, however, that I am not using the version from your screenshot. In my version there is a dot after the numbers. This is important for readability. In the example in the screenshot, there are numbers in the section names, so adding a dot matters.

36 people are now using this style even though I didn't advertise this very much. I think I mentioned it once or twice on our Polish Discord server. OK, maybe a bit less then 36 people, because e.g. I might be counted twice with my 2nd computer at work ;). Also don't know if Stylus shows uninstalls as -1.
https://userstyles.world/style/5790/wikipedia-toc-tweaks

So all in all, it may not be very reliable measurement for the popularity of the table of contents numbering function, but you can see that there is at least some demand. Enough to make a few extra clicks.

Hi. Enumerations in the new ToC has been requested on fr-wp Village pump (for example there and there). As the new ToC was criticised by several wikipedians, it was said to them that the lack of enumeration was taken into account . As there is a CSS code that works, I don't understand why it's not implemented as a clean option (for editors not familiar with using CSS). Best.

@Nux could you clarify if you think the numbers are helpful because they make it easier to distinguish h2s from h3s from h4s, or if they just make each heading easier to distinguish from the one above/below it? Two thoughts that come to mind:

  • If it's just about distinguishing the headings from the ones above/below them, that might be an indication that we need to increase the spacing between them. Also, adding the standard list indicators could help with that, for example:
    Screen Shot 2022-12-13 at 12.44.57 PM.png (862×1 px, 689 KB)
  • If it's about distinguishing the heading levels (h2 from h3 from h4s, etc.) then again spacing/indentation could help (though it comes at the cost of additional line wrapping). Another thing we could explore is adding some kind of indicator that appears when you hover over the table of contents, for example:

Numbers are helpful on pages like https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Guild_of_Copy_Editors/Requests and https://en.wikipedia.org/wiki/Wikipedia:Templates_for_discussion#Current_discussions, where it is helpful to see how many open requests or discussions are pending in a given section.

For the Guild of Copy Editors page specifically, we track the count of open requests periodically (including daily during events), so someone needs an easy way to count requests.

could you clarify if you think the numbers are helpful because they make it easier to distinguish h2s from h3s from h4s, or if they just make each heading easier to distinguish from the one above/below it? Two thoughts that come to mind:
If it's just about distinguishing the headings from the ones above/below them, that might be an indication that we need to increase the spacing between them. Also, adding the standard list indicators could help with that, for example

@alexhollender_WMF Bullets would mostly work for me, but I second what Jonesey95 said. It sometimes helps to know how many section are there. Especially in various discussions (less in articles).

I think a compromise might be to keep just a single level of numbers.

So this is with multiple levels 1.1.1.1.1... (content: counters(tocsection, ".") ". ";)

obraz.png (815×244 px, 22 KB)

This would work for readability and counting open requests etc. (content: counter(tocsection) ".";). Also adjusted 2nd level padding to make next level gap more clear (#mw-panel-toc li li::before { padding-left: .5em; }).

obraz.png (815×244 px, 22 KB)

Not sure if you would consider this aesthetically appealing :-) Looks OK to me.

Two levels of numbering is extremely handy (4.1 ... 4.12). After that you could shorten back to the last number. Most readers will not encounter a TOC that deep.

ovasileva triaged this task as Medium priority.Mar 20 2023, 3:55 PM
ovasileva moved this task from Not ready to estimate to Groomed on the Web-Team-Backlog board.

Most articles on Wikipedia are not written in a way that require the reader to read each section sequentially (in fact most people don’t read entire articles, they skim to a specific section). In this scenario, I don’t see how the position of a specific section in the article (visualized by enumeration) provides much value to most people.

That being said, there are plenty of situations where this information might be valuable. In addition to talk pages and the editing workflows mentioned above, in projects like Wikibooks or Wikisource, where books have chapter numbers and tutorials have sequential steps, numbering the ToC (or even making it wider) could be beneficial.

This might be a good candidate for the anonymous user preferences we're exploring in T333867 (given it's a CSS-only solution).

Hi @alexhollender_WMF. Dec 2 2022 you gave useful CSS to enable TOC numerotation. It doesn't work anymore. Do you know how to make it work again? Best.

See https://en.wikipedia.org/w/index.php?title=User%3AJonesey95%2Fcommon.css&diff=1154292956&oldid=1153918613 for changes that fixed it (temporarily) for me. WMF staff have been changing CSS classes at least once a week for the past few months, necessitating a sort of "Whac-a-Mole" updating of custom CSS.

@Jules78120 Stylus CSS seem to be more stable if you want:
https://userstyles.world/style/5790/wikipedia-toc-tweaks

The numbers are a bit smaller now (since a week or so), but I like it that way.

obraz.png (458×234 px, 12 KB)

Thanks for the info to both of you!

WMF staff have been changing CSS classes at least once a week for the past few months, necessitating a sort of "Whac-a-Mole" updating of custom CSS.

@Jonesey95 yeah sorry about that, a lot of it is due to our caching infrastructure and how we have to ship all css for enabled and disabled features in the same bundle.

Regarding CSS to show the ToC numbers, the following code might be more robust (and it won't place a '0.' in front of the "(Top)" link) :)

.vector-toc-numb {
    display: inline !important;
    padding-inline-end: 0.5ch;
    color: #202122;
}

.vector-toc-numb:after {
    content: '.';
}