The bug happens on all StackExchange pages.

In Firefox settings, I have Zoom > Zoom Text Only enabled (I don't like the whole-page zoom behavior). This of course makes many sites look kinda ugly when zoomed with CTRL++ but I don't care that much. However, there are some kinds of bugs that can be easily fixed.

The particular bug I mean manifests itself on home pages of each service: after pushing CTRL++ twice from normal level (CTRL+0), the list of questions has a huge blank space on the left, like on the screenshot:

css error 1


The fix is one-liner CSS:

#question-mini-list {clear:both;}


Well, perhaps this is a bit of Firefox bug in this respect... But the text-only zooming in Firefox worked like this since I remember (this was even the default-and-only behavior until sth like Firefox 3.0 or 3.5 or 3.6), and there always have been lots of pages with this issue. I haven't really investigated thoroughly how the feature works internally, but

  • perhaps they have some reasons to implement it this way
  • I'm asking for simple CSS fix which I've already provided
  • you already have clear:both; in the <div> just before the <div> I'm talking about ;)
  • In fact the only reason why the layout doesn't crash right now (even without text zooming!) is that the rules
.subheader {height: .. }
.subheader h1 {line-height: ..} 

have pixel-perfected values, equal to 34px now. Try changing the height for instance in Firebug by adding a few pixels more (in default zoom size), and you'll get a layout crash also -- this would be a standard CSS behavior, because the floated container overflows, and the other one with the default value of clear=none will have to move. Illustrated below:

css error 2

After adding the fix, there will be no layout crash, regardless of the values provided in the mentioned rules.

Edit one year later: I wrote a simple userstyle and userscript to get this fixed for interested users.

  • Sounds more like a bug report for Firefox concerning their "Zoom text only" mode...
    – animuson StaffMod
    Jul 4, 2012 at 21:58
  • 1
    @animuson I disagree. Safari's text-only zoom produces the same behaviour. Chrome's font size setting does something similar if turned all the way up.
    – Jeremy
    Jul 4, 2012 at 22:14
  • @animuson please see the update.
    – jakub.g
    Jul 4, 2012 at 22:24
  • I can't find the duplicate at the moment, but we really don't support this. If you zoom parts of the page, expect it to break. IMO, you can't reasonably expect enlarging parts of the site not to break things. Maintaining all of our designs to support that behavior isn't where we want to spend our design resources...there are much more useful things underway. Don't take this to mean I'm neglecting the usability/accessibility argument... I'm not, the zoom all satisfies that need. Edit: here it is Jul 5, 2012 at 2:16
  • @nick we are "officially" supposed to support font-only zooms of +1 and -1, anything higher or lower we require full-page zoom. Not sure if that is what we're seeing in the above screenshots. Jul 5, 2012 at 7:20
  • 1
    @JeffAtwood yes, this is at zoom level +2. Like I wrote in the post (probably not straightforward), I don't require you to create a flawless design for all the pages and all the levels of zooming and as a web-dev, I understand this is non trivial and energy-consuming (sth like supporting IE6,7,8,9,10 at once;) But in this case I've provided you a fix so I hope you'll find time one day to deploy it ;) Regards.
    – jakub.g
    Jul 5, 2012 at 8:00
  • @jakub we always appreciate bug reports that have the fix provided :) Jul 5, 2012 at 18:13
  • While we're waiting for the SE folks to get around to fixing this, I've incorporated your user style into a collection of small user script fixes that I'm calling the Stack Overflow Unofficial Patch. Thanks! Jan 14, 2014 at 17:49

1 Answer 1


This bug appears to have been fixed at some point. I am no longer able to reproduce this bug using the given instructions (which did work in the past), and examining the HTML code shows that the #question-mini-list div is now wrapped in another div designated as #qlist-wrapper, which is styled as:

.home-page #qlist-wrapper {
    clear: both;

Thus, this seems to be now.

(However, there's a similar issue affecting user profile pages that does not seem to have been fixed on SO yet, although the new meta.SO design seems to be free of it. If it doesn't get fixed by the upcoming design update, it might be worth filing a separate bug report about it.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .