Last modified: 2014-09-24 01:31:34 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 :)
Created attachment 228 [details] Patch (diff -u) Patch is available
Created attachment 229 [details] The replacement function in plain code
Please stop marking bugs as fixed when there is not a fix in the mainline CVS code, thanks.
Created attachment 286 [details] Revised patch - valid HTML. Patch against REL1.4beta6 See bug 1457. This version has balanced columns and good html.
Created attachment 4127 [details] Update of patch to apply to trunk as of r25921
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.
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.
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.
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.
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.
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.
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...
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.
