Last modified: 2014-05-21 19:34:31 UTC
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.
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 [details] 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.
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.
