Width of the content div and blocks-system-main div

I can confirm this bug.... Marking as critical because it makes the theme unusable without hacking fusion core files or CSS hacks...

I also confirm this bug. This theme is way to complex to figure out where the bug is exactly but it appears the grid class is overriding the style setting of 100%. Seems the grid class should not be applied that deep as its already applied at div #content-group. Shouldn't it not be applied anywhere deeper than that div?

I also have this problem - using the D7 version, no skinr or anything. Content in content-content is running into the gutter.

Coming here from #1057014: D7/IE6 sidebar-second layout broken in Fusion Starter. In IE6, with the fixed grid layouts (12 or 16), with sidebar-second set to be to the right of the main content (i.e. either "Split Sidebars" or "Both Sidebars Last", blocks in sidebar-second drops below the main content. A similar issue occurs when "Both Sidebars First" is selected - blocks in sidebar-second stay in their correct column, but are vertically lower than the bottom of the main content.

Removing the gridXX-XX classes from #content and #block-system-main fix the issue in IE6 in at least one instance, so these issues appear closely related.

I could be barking up the wrong tree, but I'm wondering if this bug is not related to:

Content region is now mandatory, main page content became a block

(issue) In Drupal 6 and before the $content variable in page.tpl.php contained the main page content appended with the blocks positioned into the content region (if you had that region defined).

In Drupal 7, $content became a full region and is now mandatory in all themes. This new requirement was set up so that when enabling new themes, Drupal knows where to put the main page content by default.

In Drupal 6, it was only possible to put blocks after the main page content in this region. The only way to put blocks before the main page content was to define a specific region for that purpose. Drupal 7 now makes the main page content its own block. This makes it possible to put blocks before or after the main page content in the region without hacking in a new region.

If you relied on the fact that blocks were only put in the sidebars and therefore got their styling via just a .block class selector or something similar, now you might need to revisit your CSS files. Because the main page content is wrapped by markup from block.tpl.php, the .block selector will match that too, so you need to limit your blocks styling to certain regions by making the selectors more specific, such as #left-sidebar .block.

Added a check to the block and region preprocess functions to return without changes if the region is set to content. This removes the grid class from #content and #block-system-main and seems to fix the issue. No idea about possible side effects.

It's working. I Don't see any effects for the moment. Thanks again IntoTheWoods!

Thanks everyone, yes this is a big pain and going to the content block has made this whole content area even more nesty and complicated in D7. We're going to be talking about the best way to solve this next week at Drupalcon. Thanks for the input so far.

Any results from the discussion on Drupalcon?

+ subscribing

Yep, and we had some post-Drupalcon illness+vacation but this is top priority in the next few days.

I confirm this bug. The solution proposed at #8 works for me.
#1113620: Content area resizes when adding a block

As mentioned in comment #7, Drupal 7 now has a mandatory content region that replaces the D6 $content variable in page.tpl.php. In the D6 branch of Fusion, we add extra wrappers to $content to render it similar to regions. That D6 code was inherited in the D7 version of Fusion, which causes this display issue (no gutter space between the content region and sidebar).

The patch proposed in #8 does work, and will be easier to apply if you've already started your D7 subtheme. Alternatively, or if you're just starting a new Fusion 7 subtheme, deleting some of the wrapping <div> elements in page.tpl.php will get deeper to the root of the issue. This attached patch removes those wrapping elements from the starter theme's page.tpl.php:

#content-group, #content-region, #content-inner, #content-content

This will fix the display issue in the standard starter theme, but the starter_lite theme still requires work. I'm working on that one.

Hi aquariumtap, I made the changes to my subtheme and it did fix some of the issues. One thing I noticed is that the margins are being applied twice to the content block.

I see the following Divs

<div id="content-inner" class="content-inner inner"> 
      <div id="block-system-main" class="block block-system first last odd grid24-8">
  <div class="inner clearfix">
    <div class="content clearfix">
    <div class="inner content"> 

The two inner classes both apply the margins so I end up with the wrong sized area for my content.

As a hack for now I have added the following to my CSS

#content-inner .content { 
  margin-left: 0;
  margin-right: 0;
}

The patch from #14 may cause problems with sidebar-second and fluid grid widths. I recommend updating Fusion to the latest version (as of 10 may 2011: the alpha release).

I was experiencing this issue as well.
Upgrading to the latest 7.x-1.x-dev seems to have addressed the situation for me.
Thanks aquariumtap!

An unintended result, however, is that the grid overlay columns have lost their gutters. I've just opened #1153598: Overlay grid missing gutters.

Is this a problem in other themes? Does the zen subtheme starter use the same 960 width class?
Am I hearing that there is only a fix in drupal 7 -- not 6?

I just ran into this issue with the latest version of Fusion Starter when using the Nodes in Block module which worked as advertised in Sidebar first but failed in Sidebar second (dumping the material below the Content region). Material in blocks display fine when placed in the Sidebar second region btw.

cstalberg, are you using Drupal 6 or 7? It is possible that the Nodes in Block module is adding some CSS that is interfering with the Fusion grid framework. Could you provide a link to your site demonstrating the issue for further investigation?