Page MenuHomePhabricator

With no text content in footer, footer becomes shorter than image content
Closed, ResolvedPublic


Author: dean

When a skin is adjusted to have less items in the footer, and a particular page has
the remaining ones disabled, the height of the footer shrinks to less than the height
of the contained images.

This is visible (at least in IE7) on one of my history pages:

I have the footer list set to:
$footerlinks = array
('lastmod', 'viewcount', 'numberofwatchingusers', 'credits', 'copyright', 'tagline');

Version: 1.11.x
Severity: trivial



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:13 PM
bzimport set Reference to bz5798.
bzimport added a subscriber: Unknown Object (MLST).

dean wrote:

Screenshot of the problem

This shows the bug in action


wikibug.png (768×1 px, 104 KB)

dean wrote:

I've tried giving it a fixed height but then it wont expand to show the text when
its in there.
Unfortunately, I don't know enough CSS to do it properly.

robert wrote:

This is a problem with the way divs work. The div is only the height of the actual content - so placing a non-breaking space at the base of the div (below everything else in it) will solve the problem. I have also experienced a similar problem before with Google siteads - this is a problem with your wiki and a solution needn't be put in the codebase as it is not a problem for users who aren't messing about with the files.

ayg wrote:

We could add a min-height rule for the footer, but that would cause trouble for people customizing the skin in a different way (i.e., replacing the images with shorter ones). I concur that this is not an issue reasonably fixable by MediaWiki.

webboy wrote:

You could add <div style="clear: both;"></div> to the end of the footer.

ayg wrote:

Problematic as-is because in the default setup, that shoves down the lower border, due to padding. Possibly something based on that idea would work, however.

On consideration, we do allow people to configure away all those messages at the bottom without hacking the files. So we should probably support it looking good without manual CSS modifications if you do that, although it's not very important. Reopening in case someone can come up with a good solution that won't change existing layouts.

Related URL: (Gerrit Change I337bab53600efb4cb27b65b01d62f59968a4fba9) (Gerrit Change I337bab53600efb4cb27b65b01d62f59968a4fba9) | change APPROVED and MERGED [by jenkins-bot]

TheDJ assigned this task to Sophivorus.
TheDJ added a project: MonoBook.
TheDJ set Security to None.
TheDJ removed a subscriber: wikibugs-l-list.