I've been thinking about a flexible way to layout blocks on-the-fly using the grid system. Programatically, we can automatically detect the total number of blocks in a region and give each block a grid-X width that works (assuming there are either 2, 3, 4 or a multiple of three or four blocks). But what if we want to get 4 blocks in a layout ordered like this:

[grid-1] [..............................grid-6.............................] [............grid-3............] [......grid-2......]

The other question is would this even be necessary during the lifetime of the d.o and family of subdomains also using the bluechees theme?

One solution might be to allow us to specify a grid-X class in the block configuration page like the Block Class module. This would obviously require us getting approval to get a new module installed (or supplying a patch into one of the existing drupal.org custom modules).

CommentFileSizeAuthor
#3 650128_1.patch5.16 KBjwilson3
#1 650128.patch6.65 KBjwilson3

Comments

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented
StatusFileSize
new 650128.patch6.65 KB

I'm working on some prototypes in my sandbox of the 'autodetect grid width' , but figured I'd submit a patch here too. This issue should be moved to the bluecheese issue queue i suppose, no?

My patch patch also includes block support for 960.gs alpha and omega classes, as well as cleans up a couple whitespaces in the template.php file.

I'm not totally happy with the grid detection logic yet. At the moment, it just checks to see what region the blocks are in (so that we don't add crazy grids to the right-sidebar).

The final logic should be something like:

/// pseudo-code
is the $count of blocks a multiple of 4? then make them grid-3
if not, then is the $count of blocks a multiple of 3?  then make them grid-4
if not, then is the $count of blocks a multiple of 2? them make them grid-6
if none of these, then dont add any grid.
jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented
Project: Drupal.org Redesign » Bluecheese

moved the issue to the correct queue.

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented
Status: Active » Needs review
StatusFileSize
new 650128_1.patch5.16 KB

updated the logic for auto-detect grid width.

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented

In addition to the Block Class module mentioned in the original post, another module I found that might be an excellent fit for ultimate flexibility with respect to adding new page elements on the grid is the Skinr project: http://drupal.org/project/skinr this looks really interesting.

budda’s picture

budda
Primary language English
Location Cheshire
commented

I'm one part of the team responsible for the about page.

We were considering something along the lines of the block module route, but the unified grid output via template.php would make sense.

We not had time to actually look at the project yet though.

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented

I'm already having second thoughts about my automated detection patch. It could really end up causing lots of havoc with people's custom blocks. I think the best way to handle this is let custom blocks define their css classes in hook_block() (is it possible?), and/or enable block class customization in the Block admin / edit screens.

If we dont open up the ability to the admin panel to customize the block class, then at the very least, the theme would need to use one key part of my patch above so that it doesn't overwrite and erase the block classes that our modules try to add.

Index: template.php
===================================================================
--- template.php (.../bluecheese/trunk/template.php) (revision 2080)
+++ template.php (.../sandbox/jrguitar21/bluecheese/template.php) (revision 2082)
@@ -172,7 +172,7 @@
*/
function bluecheese_preprocess_block(&$variables) {
// Add block classes
- $variables['block']->classes = 'block block-'. $variables['block']->module;
+ $variables['block']->classes .= 'block block-'. $variables['block']->module;

drupaltronic’s picture

drupaltronic commented

Using this great skinr-module you can put many blocks in a content area and set the width as you want (within 960) : see demo here :
http://www.drupalthemeplayer.com/ : here I've simply put some blocks in the secondary content and in the tertiary-content
and http://www.drupalthemeplayer.com/testpagina : here I've omitted the sidebars and put some flexible blocks in the main content area.
Easy as one two three and ultra flexible !

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

I think Skinr makes a lot of sense on sites where the admin (who is not a css designer) is trying to do design. I like Skinr quite a bit in that scenario.

On drupal.org the admins and site builders are fairly sophisticated and comfortable making css changes ;) I don't think we should add this relatively new module to a site that has a solid and active gorup of designers able to make these changes.

Each new module on Drupal.org is a huge baggage to carry forward - even if skinr has a 7.x alpha release we just don't know how well it will be supported in the future or how well it handles a high traffic situation like drupal.org.

The alternative as I understand it is to add the necessary classes in a custom module/theme function which will grow our custom code by a few lines of simple code per block.

In comparison, skinr is about ~1,500 lines of custom code. That's not huge by any means, but it's enough that we should think hard about how much benefit it might give us.

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented

greggles, you have a very valid point about module bloat and being skeptical of adding new modules.

"The alternative as I understand it is to add the necessary classes in a custom module/theme function which will grow our custom code by a few lines of simple code per block."

This is correct. However, it then also ties block presentation/layout to the custom module/theme code. By contrast, skinr (or another similar block class module) would decouple the need for presentation to be "set in stone" in custom module/theme template files and let the person assigning a block to a region in the admin section also arrange the grid presentation.

This brings up a well-weathered (albeit admittedly bikeshed) issue... is marrying presentation into structure a good or bad idea? It feels like Drupal takes a general stance against it. If a block gets moved or added (lets say in the admin interface) to another page, the module code that might have set a 'grid-2' class for a specific block might need to be changed / tested and pushed to production. (This is where the advantage of the skinr module in the admin interface becomes apparent).

Personally, I've always been a fan of zen-like themes where you have semantically descriptive css classes applied to blocks, and use them to assign presentation in the stylesheet. For example the #contact-form gets a float property and column width (effectively, the same thing as adding a grid-X class to the form tag). We could always still do this with Blue Cheese (using existing CSS classes assigned to each block in combination with body class to identify/single-out the page if necessary). I claim though that 1) this will add unnecessary CSS bloat and 2) is incorrect usage of the 960 grid system.

But with the Blue Cheese architectural decision to implement with 960.gs, having and then not using the system to layout blocks/content feels awkward. It begs the question, why are we using a grid system in the first place?

todd nienkerk’s picture

todd nienkerk commented

jrguitar: Thanks for your work so far on Blue Cheese. I'm one of the people responsible for the architecture of the theme so far, a proponent of 960.gs, and the maintainer of the Block Class module. Here are my thoughts on this thread so far:

(1) Automatic grid-sizing logic. Can you give an example of when a grid size would need to be assigned dynamically -- especially to a block? I'm not entirely convinced there's a use case for this. As greggles discusses above, Drupal.org admins are very knowledgeable people. If they need to be told to manually assign a grid class when adding a new block, they'll do it without any difficulty.

(2) Use of grid classes on blocks. It's rather unusual to assign grid classes to blocks -- they're usually used on the regions that surround the blocks. In cases where blocks are laid out horizontally (as you outline in your original post), it's usually better to assign grid classes in the markup or UI using something like Block Class or Skinr. If there's a good chance this could break the layout for some unforeseen reason, I suggest creating regions that lock those blocks into specific, predetermined widths. You can then use the ns() function supplied with NineSixty to dynamically adjust widths, pushes, pulls, etc.

We use NineSixty on the Four Kitchens website to assign widths to regions and blocks. Here's a diagram that helps explain how we do this: Horizontal blocks inside a region using NineSixty. The diagram was taken a session I co-presented at DrupalCon Paris: Accelerated grid theming using NineSixty (PDF) (see slide #96).

(3) Block Class vs. Skinr. For the purposes of Drupal.org, I'd suggest Block Class. It's very lightweight and requires only a small snippet of PHP in the block.tpl files. Skinr will make Block Class obsolete one day -- it's a very, very cool module -- but it's still in its infancy, and it's overkill for what we need on Drupal.org.

(4) Why are we using a grid system? We're using a grid system so we can create page layouts quickly without wrangling pixel widths, negative margins (for push/pull), and other annoying stuff that can easily abstract something easy to confuse like "220 pixels wide" into something much simpler: "three columns." Additionally, the site was designed on a grid, so the translation is very easy.

I think point (2) above is important in this context. By getting lost in the debate over whether to use grid classes on blocks, it's easy to forget what they're usually used for: regions.

Kendall Totten’s picture

Kendall Totten commented

One of the biggest aha moments I've ever experienced was discovering the Block Class module:
http://drupal.org/project/block_class

It was also the missing piece in figuring out how to work with the Zen NineSixty theme. I wrote up a few notes on the working with the grid theme here: http://switchbackcms.com/blog/zen-ninesixty-theme

Hope it helps!

-Kendall

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Needs review » Closed (works as designed)