#main-wrapper min-height causes footer not to show without scrolling

OK, but what I really would prefer to do is change to a sticky footer, if that is possible in the time frame - the reason for this is #937602: Ugly black header background when horizontally scrolling, so it would actually solve both issues quite nicely.

I think we should seriously entertain the sticky footer concept again, we talked a lot about it in the past and even wrote some patches that did work quite well. Lets give it a crack.

#888412: Make footer stick to the bottom of the page was where we originally tried to address this.

bleen pointed out (http://drupal.org/node/888412#comment-3356012) a lot of ways for a sticky footer to go wrong. I think it would be great to get it working, but I'm not sure how feasible that is in the given time.

@webchick - no it wouldn't be like a frame, it would work like this: when the page content is shorter than the height of the browser the footer sits on the bottom, however, pages with content push the footer down like any normal page - you can see an example here: http://ryanfait.com/sticky-footer/

@tim - most of that is discussion regarding a JS sticky footer, which is quite hard to make work in a generic theme (without massive engineering, I mean I have scripts that are just monsters for doing JS sticky footers), however that's not what I am thinking here.

Lets just scope this out a bit:

1) A sticky footer could be a solution, if we can make it work, I know I have the CSS skills to pull it off - but I/we don't have very much time.

2) Possible better solution is forcing the footer to expand to fill the rest of the page and setting a very low min-height (maybe not at all), I really dislike the min height because we never know the height of the view port (think mobile, could be very small). It may look like that's how it works now, however it does not, its merely a visual trick that has the drawback of the issues in #937602.

If we decided to live with the issues in #937602 then we could, feasibly, simply remove the min-height and this issue is indeed a quickfix.

Getting the screen shown at the top is also a factor of screen real estate, I never came across it on my 20" monitor. Content will normally determine height, but to keep it from being too small a min-height of 325px could be set on #content rather than #main-wrapper. I was also able to get rid of the ugly black with some changes to layout.css and colors.css. I don't think I know this stuff well enough to generate a patch, but here is what I did:

In layout.css I
gave #main-wrapper a width of 960px
gave #page-wrapper and # header a min-width of 960px
changed the min-width setting to 325px for #content instead of #main-wrapper

In colors.css I gave #main-wrapper a background color of #ffffff

The 1st attached image shows bartik with horizontal scroll bar all the way to the right and the 2nd shows bartik with no horizontal scroll bar.

Actually I didn't need to do anything to #main-wrapper. Giving min-width to #page-wrapper and #header were enough.

Some good lateral thinking dcrocks, lets give that a go and at least test it out. No great support for IE6 but not exactly broken either.

I don't have anything to test IE6 but it looks to me like the min-height on main-wrapper should be a little larger. On a vanilla out-of-the-box drupal the 1st side bar is a little taller on the front page than on internal pages, causing the screen to 'jump' after logging in.

Well it was just an arbitrary number so 300 seems as good as 265. We could add a height for IE6 actually, it treats height like min-height. Lets test with this, if its deemed appropriate we can add in the height for IE6, but as for min-width - supporting this is IE6 requires some hoop jumping with CSS and frankly I think its all a bit late for that (would need some serious testing as it can require floats, negative margins etc etc to emulate real min-width).

I should think these things through. I have my browsers default font size set to 18px, which of course effects the height of the sidebar. Still, in general their are problems with bartik elements at larger font sizes. Input boxes tend to to be too large for the containing area and conceptual link hover icons can overlap the search box. I think the current compromise should be designed for a larger font size.

Well, at 300px the breadcrumb can appear and still not affect the min-height on a standard install, for the few pages that are available outside the overlay. I hear you on these other issues, problem is we don't have enough people posting issues and patches to help fix them, its tough enough just fixing the really critical issues - I'm struggling the get reviews for some really fundamental patches as it is. Patches and reviews welcome :)

I tried it in safari 5, opera 10.6, chrome, and ie8 and it seems to be fine. On my wife's little 9" netbook, scrolling is a way of life. To me, a sticky footer in bartik is kind of tall and I'd rather not have it on short browser windows.

ps. #footer width set in 2 different places to 2 different values: Lines #11 and #92 in layout.css.

@14, its deliberate, we want #footer to get the margin values from the first declaration, rather than having to re-declare the auto margins just for #footer.

This will eventually be obsoleted by #888412: Make footer stick to the bottom of the page. jensimmons and I both like this. Good compromise.