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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 900 - Category page listings have unbalanced columns
Category page listings have unbalanced columns
Status: NEW
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
1.24rc
All All
: Lowest minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://digital-conquest.ath.cx/wiki/i...
: design, patch, patch-reviewed
Depends on:
Blocks:
  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: ---


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

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.

Example: http://u-br.net/wiki/Categoria:Cursos_de_Gradua%C3%A7%C3%A3o

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:

https://en.wikipedia.org/wiki/Category:History_of_the_United_States_%281849%E2%80%931865%29

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.

https://en.wikipedia.org/wiki/Category:History_of_the_United_States_(1849%E2%80%9365)

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.


Navigation
Links