Page MenuHomePhabricator

Kill section auto-numbering
Open, LowPublic

Description

Section auto-numbering (https://www.mediawiki.org/wiki/Manual:Table_of_contents#Auto-numbering) is, IMO, one of the worst ideas in MediaWiki that has survived to the present day. It makes every article look like a legal treatise instead of something designed to be read by a normal human being.

Strangely, you can actually add auto-numbering to the headers themselves (an even worse idea), but you can't remove it entirely.

It's time for us to adopt a kinder, gentler table of contents and get rid of all the '3.2.5.1's and '2.3.2.2's. I'm sure many years ago (when most articles were stubs or only had one level of headers) it seemed harmless enough, but these days some ToCs have more numbers than words.

I see that WikiVoyage has wisely decided to eschew the numbering. We should learn from our new comrades and adopt this strange but elegant Western fashion as our own.

My proposal would be to turn off all auto-numbering by default, but allow any hard-line loyalists to re-enable it in the preferences. The option to turn on header auto-numbering, however, should be sent to the firing squad.

If this is deemed too radical by others in the politburo, perhaps we could at least introduce an option to turn off auto-numbering in the preferences for those wishing to escape the tyranny of numbers.


Version: 1.21.x
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=6453

Details

Reference
bz42059

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:01 AM
bzimport set Reference to bz42059.
bzimport added a subscriber: Unknown Object (MLST).
kaldari created this task.Nov 13 2012, 8:15 AM

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.

Danny_B added a subscriber: Danny_B.Feb 1 2016, 2:13 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 1 2016, 2:13 PM

! 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.


or at Barack Obama:

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.

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