Page MenuHomePhabricator

Category page listings have unbalanced columns
Closed, ResolvedPublic


Author: perl_dummy

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 :)

Version: 1.24rc
Severity: minor



Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 7:09 PM
bzimport set Reference to bz900.
bzimport added a subscriber: Unknown Object (MLST).

richholton wrote:

Patch (diff -u)

Patch is available

attachment categorypagediffs.txt ignored as obsolete

richholton wrote:

The replacement function in plain code

attachment temp.txt ignored as obsolete

Please stop marking bugs as fixed when there is not a fix in the mainline CVS code, thanks.

richholton wrote:

Revised patch - valid HTML. Patch against REL1.4beta6

See bug 1457. This version has balanced columns and good html.

attachment CategoryPage.php.patch ignored as obsolete

Created attachment 4127
Update of patch to apply to trunk as of r25921

attachment bug900.diff ignored as obsolete

Created attachment 4129
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.


alxndr wrote:

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.


bugs wrote:

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.

sumanah wrote:

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.

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.

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

epriestley closed this task as Resolved by committing Unknown Object (Diffusion Commit).Mar 4 2015, 8:20 AM
epriestley added a commit: Unknown Object (Diffusion Commit).

Accidental clash. Known issue. Reverting status.

matmarex claimed this task.
matmarex subscribed.

This has been fixed by T55130.