The numbered headings slightly increase scannability of wrapped headlines.

Compare:

1 This is the long long Heading of
Doom that continues
2 This is another heading
3 This is another heading

with

This is the long long Heading of
Doom that continues
This is another heading
This is another heading

I tried browsing en.wp for a while with tocnumbering off but found that loss of scannability too annoying. YMMV and I have no strong view on what the default should be. However, it might be nice to adjust the layout to address this scannability issue.

An alternative to disabling numbering altogether would be to disable it at a high nesting depth. If lots of folks like having the numbers, that might be a good compromise that doesn't require the addition of Yet Another Preference.

I don't think I've ever seen a wrapped ToC header on Wikipedia. Even when loading Barrack Obama on my iPhone (980px wide viewport), which has headers like "University of Chicago Law School and civil rights attorney", the headers don't wrap, and in fact could be much longer. Even at 640px, the vast majority of articles don't show any ToC wrapping, but often have other layout problems.

Created attachment 11358
TOC word wrap on https://en.wikipedia.org/wiki/Acra_(fortress) (with numbering turned off)

I see it on lots of articles, but that appears to actually be a weird bug/behavioral difference in Chrome 22.

As an example, the attachment shows the word wrap on https://en.wikipedia.org/wiki/Acra_(fortress) (with numbering disabled; the wrap is identical with numbering enabled). It wraps well before it's necessary to do so. I've confirmed this behavior in logged out user sessions and in Chrome 22 on Windows as well (via CrossBrowserTesting.com).

Firefox 16 and Chrome 23 do not exhibit this behavior; haven't tested other browsers. If it's not widespread and perhaps even entirely specific to Chrome 22 it may be a non-issue.

Attached:

That's certainly strange. There's nothing in the ToC that should be causing it to wrap prematurely (no set widths). From the looks of the screen-shot, it seems to be a miscalculation in Chrome. A couple more pixels and it wouldn't have wrapped. I checked in Safari, which also uses WebKit, and it doesn't wrap either. Looks like it may be specific to that version of Chrome.

Related: T92481: Line break and indent for long entries in TOC Since currently the main reason for not removing the numbers is the fact, that line breaks are hard to recognize, adding proper indention for TOC entries will allow to remove the numbers as proposed.

! In T44059#456974, @kaldari wrote:
I don't think I've ever seen a wrapped ToC header on Wikipedia. Even when loading Barrack Obama on my iPhone (980px wide viewport), which has headers like "University of Chicago Law School and civil rights attorney", the headers don't wrap, and in fact could be much longer. Even at 640px, the vast majority of articles don't show any ToC wrapping, but often have other layout problems.

It depends what window-size (as well as screen-size) is being used, and also if there are images/infoboxes/navboxes in the lede section. E.g. at https://en.wikipedia.org/wiki/List_of_countries_by_Human_Development_Index I get this linewrap, with and without section numbering.

In T44059#1112311, @Schnark wrote:

Related: T92481: Line break and indent for long entries in TOC

Possibly that should be re-opened as unresolved, per my examples above? It didn't indent the line-wrapped portion to a deeper amount than the other headings at the same H-level, which it should do.

Since currently the main reason for not removing the numbers is the fact, that line breaks are hard to recognize, adding proper indention for TOC entries will allow to remove the numbers as proposed.

Additional reasons, especially on highly active discussion pages such as the Enwiki Village Pumps, are:

• some editors use the numbering to remember "where they were" on the page (e.g. "the topic I was looking at yesterday was roughly #54, so it'll be there or higher in the ToC", or ,
• to get a sense of how busy the page is on that day. For example https://en.wikipedia.org/wiki/Wikipedia:XfD_today has 131 sub-sections within section 2 today. Or "Good grief, there are 15 new sections since I last looked at this page"

Note: This was also discussed in some section of the Typography Refresh, during the period of time that a new ToC design was part of that. E.g. https://www.mediawiki.org/wiki/Talk:Typography_refresh/Archive_2#TOC_broken and other sections in the 4 pages of archives.

Possibly that should be re-opened as unresolved, per my examples above? It didn't indent the line-wrapped portion to a deeper amount than the other headings at the same H-level, which it should do.

It should probably only indent further if the numbers are removed at the same time. An alternate solution would be to replace the numbers with bullets, in which case further indentation would be unnecessary.

Additional reasons, especially on highly active discussion pages such as the Enwiki Village Pumps, are:

• some editors use the numbering to remember "where they were" on the page (e.g. "the topic I was looking at yesterday was roughly #54, so it'll be there or higher in the ToC", or ,

Citation needed. This seems very implausible to me. Sections don't stay at the same number on places like Village Pumps. It's much more useful to hit Command-F and enter some words related to the discussion. It's easier to remember words from headers than it is to remember random (frequently changing) numbers.

• to get a sense of how busy the page is on that day. For example https://en.wikipedia.org/wiki/Wikipedia:XfD_today has 131 sub-sections within section 2 today. Or "Good grief, there are 15 new sections since I last looked at this page"

You can do this just as easily by looking at how long the list is. Either way, being able to say "Good grief, there are 15 new sections since I last looked at this page" is hardly a good reason to keep a bad UI.

With proper indentation and bullet points would make much better appearance

@alexhollender will this be dealt with as part of desktop improvements when we work on table of contents?

In T44059#6745467, @Jdlrobson wrote:

@alexhollender will this be dealt with as part of desktop improvements when we work on table of contents?

we will be reevaluating this pattern, yes. There is some good context in this task so it would be nice to make it a subtask of the ToC epic once it exists.

@kaldari

mw.util.addCSS('.tocnumber{display:none}')
for(toctextint=0;toctextint<$('.toctext').length;toctextint++){
	if ( $('.toctext')[toctextint].innerText.length > 80 ) {
		$('.toctext')[toctextint].innerText = $('.toctext')[toctextint].innerText.slice(0,70) + '..';
	}
}