Last modified: 2014-09-24 01:31:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2900, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 900 - Category page listings have unbalanced columns
Category page listings have unbalanced columns
Status: NEW
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
All All
: Lowest minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: design, patch, patch-reviewed
Depends on:
  Show dependency treegraph
Reported: 2004-11-16 22:56 UTC by Tels
Modified: 2014-09-24 01:31 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Patch (diff -u) (3.23 KB, patch)
2005-01-26 05:58 UTC, Richard J. Holton
The replacement function in plain code (2.51 KB, text/plain)
2005-01-26 05:59 UTC, Richard J. Holton
Revised patch - valid HTML. Patch against REL1.4beta6 (4.01 KB, patch)
2005-02-12 16:50 UTC, Richard J. Holton
Update of patch to apply to trunk as of r25921 (3.87 KB, patch)
2007-09-18 18:48 UTC, Brion Vibber
Updated patch with tweaked comments and adjustable column count (3.94 KB, patch)
2007-09-18 19:04 UTC, Brion Vibber
clean slate; adjustable column count and headline weight (3.35 KB, patch)
2007-09-25 03:03 UTC, Alexander

Description Tels 2004-11-16 22:56:51 UTC
As seen on the sample URL, category pages have unbalanced columns. This happens
frequently (usually the middle column is way longer than the outer ones).

The reason is that the software seems to only balance the items in the columns,
e.g. with 30 items in total it will put 10 items into each column. However, if
there are many items in one column (usually starting with letter "S" :), then
the other columns will have more headers. Since headers take up space, one
column will get longer than the other ones.

A temporary and dirty fix would be to count headers, too, when balancing the
columns. This would ignore that a heading takes up a bit more space than an
entry, but heh, thats better than having 20 headings + 20 entris vs. 20 entries :)
Comment 1 Richard J. Holton 2005-01-26 05:58:34 UTC
Created attachment 228 [details]
Patch (diff -u)

Patch is available
Comment 2 Richard J. Holton 2005-01-26 05:59:52 UTC
Created attachment 229 [details]
The replacement function in plain code
Comment 3 Brion Vibber 2005-01-26 06:04:06 UTC
Please stop marking bugs as fixed when there is not a fix in the mainline CVS code, thanks.
Comment 4 Richard J. Holton 2005-02-12 16:50:09 UTC
Created attachment 286 [details]
Revised patch - valid HTML. Patch against REL1.4beta6

See bug 1457. This version has balanced columns and good html.
Comment 5 Brion Vibber 2007-09-18 18:48:05 UTC
Created attachment 4127 [details]
Update of patch to apply to trunk as of r25921
Comment 6 Brion Vibber 2007-09-18 19:04:09 UTC
Created attachment 4129 [details]
Updated patch with tweaked comments and adjustable column count

Tweaked some comments for legibility and made the column count adjustable through one variable instead of hardcoded to 3 to make it easier to test the algorithm.

There seems to be something basically wrong with the algo; items from the end of the list get dropped off pretty regularly.
Comment 7 Alexander 2007-09-25 03:03:24 UTC
Created attachment 4153 [details]
clean slate; adjustable column count and headline weight

Here's my attempt. In my tests I didn't get items dropped off the end.

Number of columns is adjustable. "Weight" of headlines (that is, how tall it is relative to a line-item) is adjustable too.
Comment 8 Juliano F. Ravasi 2008-08-18 03:24:32 UTC
Since these patches are already dealing with the columns of the category pages, I would like to ask to move the number of columns variable to DefaultSettings.php, making it a global variable.

I have a wiki with a lot of long, single-word, non-breaking page titles, that make category pages look ugly with three columns. I had to change the core wiki code in order to make it into two columns.


Also, it is a good idea to share this configuration variable with Special:Allpages.
Comment 9 Sumana Harihareswara 2011-11-06 13:42:36 UTC
This is still happening on MediaWiki 1.18 -- example:

Unfortunately, neither Alexander's patch nor Brion's patch applies cleanly to trunk (Alexander, I am very sorry that no one reviewed your patch when you wrote it four years ago).  Does anyone want to try writing a new patch that incorporates Alexander's and possibly Juliano's ideas?

Also adding the "design" keyword since a visual designer might be interested in providing a more elegant solution.
Comment 10 Daniel Friesen 2011-11-06 14:09:57 UTC
Maybe it's time we ditch the whole table based categories and start using css3's multicolumn features.

It's supported in Gecko and WebKit for ages, Opera has added support, and IE 10 now has support for it. The fallback in browsers without support is simply the category data in one column instead of 3, which still looks perfectly good and is completely accessible to the user. And if we really want column support in browsers that don't support the native css yet, there's a js library for that.
Comment 11 contrafibularity 2012-08-30 12:55:06 UTC
We're well into 2012 and I'm wondering if this has been fixed in MW 1.19 or 1.20? The page on Wikipedia that Sumana linked to looks alright to me, but it's possible that this category has changed since November 2011.
Comment 12 Jarry1250 2012-09-06 20:14:18 UTC
Fundamentally I don't think this bug is fixed, no: if you count up the number of entries in each column it seems to me that they're done mathematically rather than taking into account the size of headers. Whether it's that big a deal, of course...
Comment 13 Quim Gil 2014-04-26 07:10:17 UTC
New URL, the problem persists.

Nobody is working on this currently. Marking as Lowest accordingly.

Note You need to log in before you can comment on or make changes to this bug.