Fluid grid style plugin

I don't know if it would be included but I know a lot of people would be interested in this if you could make it work well cross browser. I tried and failed to do it and ended up just using the table based grid.

Michelle

It might be of value in the Views Bonus Pack but I am pretty happy with the default styles Views ships with.

It seems it is being implemented in image_gallery module (part of image package).

However, I also need this kind of views plugin, so it would be nice if it was something that do not depend on anything else but Views.

I have it almost done as a custom module, but if no one else is going to pack this as a separate contrib, maybe I could? Would that be of interest to someone else?

Advice appreciated. Thanks! :)

In regards to cross-browser support...

li.views-fluid-grid-item {
  display: inline-block;
}
/* Holly hack to enforce hasLayout for IE7 and lower. \*/
* html li.views-fluid-grid-item {
  display: inline;
  zoom: 1;
}
/* */

In regards to the LI size thing... here's how I would do it: There could be a fixed number of plugin style options for the width, with a select element, and then use CSS classes. There shouldn't be a lot of classes, just a few to offer a common set of options 150, 200, 250, 300, 400, 500, period. This could also be extended with a Drupal variable, for example:

  '#options' => drupal_map_assoc(variable_get('views_fluid_grid_widths', array(150, 200, 250, 300, 400, 500))),

and this can be defined in settings.php like this:

$conf['views_fluid_grid_widths'] = array(150, 200, 250, 300, 400, 500, 600, 700, 800);

...or in real time, just before the plugin style code is invoked, like this:

$GLOBALS['conf']['views_fluid_grid_widths'] = array(150, 200, 250, 300, 400, 500, 600, 700, 800);

Themers would still have to extend the CSS classes for addition widths, though.

I think a fluid grid plugin for Views could be reused by many other projects, not just image module.

My main problem is that I need this asap, I do not need image module, and I would prefer using something that's published at d.o. because there are a lot more chances to discover bugs than something that is just custom (ie. no one else can see the code), so if it is not included in Views, then... what?

@joachim: Earl, said not in Views, so... would you create a separate project for this Views plugin?

I would be happy to comment in the image issues queue, but I do not need that module, I need something that does not depend on anything but Views.

So I'm now stuck in a custom solution, unless you agree to move this plugin to a separate module. If not, then I think I prefer doing it myself rather than using custom code that no one else can take advantage of.

LI sizes: yes, my code above was just an example on how default options available could be extended, but each view would have its own chance using style plugin settings.

I hesitate to speak for Earl, but I'm fairly sure he actually said this so hopefully am not speaking out of turn here. The problem with including it in Views is that anything in Views needs to be supported by Earl. So how about a compromise? If you pledge to answer any support requests related to this plugin and keep it up to date as needed, could it then go in Views? I, too, would like to see this in Views itself but can't promise to be the one supporting it and can sympathize with him not wanting to add more to his work load.

Michelle

@Michelle: I cannot imagine how can Earl deal with the whole Views and Panels monsters. It looks like he lives in a world where days have 48h or more. =:-o

@joaquim & all: I will commit (later today or tomorrow) the code I wrote to my sandbox space, and then I hope that helps to decide if it worths, or what can be done next. It is not based on the plugin in image gallery because I started to do it before looking into that. Then I realized that I would have to look a bit, because this is something that almost every image gallery might need, I thought.

ok, here we go:

http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/markus_petr...

This style plugin comes with template and .css files that can be changed at will. I have also implemented plugin options to dynamically set text-align, width, height, horizontal and vertical margins and a couple of optional CSS3 properties (box-shadow and border-radius that do not work on all browsers, but they should cause no harm, I think). I tested this on Firefox 3.5, Opera 10, IE6 today. Yesterday I also tested in IE8, but I made a few changes since then, so I'm not 100% sure everything works ok in IE8, but I'll re-check this particular case next Monday. The only problem I have not been able to solve is that ul { text-align:justify } does not work in IE6 (ignores this attribute).

Please, let me know. My personal preference is to not depend on anything other than Views.

@markus_petrux: That's my preference as well. I want to use this in Advanced Profile Kit and would rather not introduce a chain of dependencies. I already depend on Views and could add VBP if I absolutely must but depending on Image is a no go.

Michelle

I added all these options to the style plugin because it is easy to adapt from Views UI, it is more Wysiwyg. But anyway, no problem, I could add this later from custom code.

In regards to margins, paddings and alignments... this could be fixed in the default stylesheet. CSS3 stuff could also be stripped out from here as well. No problem. Easy to override from custom stylesheets.

I cannot really say I would be able to deal with issue related to this plugin from the Views queue, because it is a big, big issues queue. Maybe one day, but now I do not have the time for this. I have spent a bit more than a year already in the project I'm working on, and I need to speed up a few things that are still pending.

Not sure what else I could do now. Anyone had the opportunity to test it? Does it worth to spend time writing a patch for views?

In case of doubt, I think I'll go ahead and create a separate project. It could then mature from there, and maybe one day it is stable enough and ready for Views. It doesn't matter much to me as far as a fluid grid exists for Views in a way that can be easily reused, not only for me, but everyone else that may need this kind of layouts in Views.

Well, I need to start next week with more stuff in front of me still pending to solve, so I'm going ahead here and I have created a project page for this:

http://drupal.org/project/views_fluid_grid

Note that I have made a few changes to the code and added documentation in the README as well as in the project page.

Basic changes are that advanced stuff is fully optional, and the corresponding stylesheets are isolated into a separate .css file, so if someone does not like this, then don't use it, and you can style using the base .css file provided. All these .css files use a name unique to the module so one can easily override them from theme .info files, etc.

I will be more than happy to provide upgrade paths from this module to a possible implementation in Views, if that happens.

In the meantime, I hope this tiny module can help others build galleries or whatever one finds use for it.

Cheers

+1 for this style plugin...
For what it's worth, I've been using http://drupal.org/project/views_fluid_grid on basekamp.com (on the events & projects pages) for a week now & no problems from what i can see. Solves something that's been nagging me... how a (fixed column number) grid display feels out of place in a fluid page layout. Thanks a lot!

.

+1
subcribing also

subscribing should this get bumped to 3.x?

Probably, though I'm not convinced it's something I want to put in Views in general. It could live very happily in contrib, I think.

are you sure you don't need more code to maintain Earl? ;)

Marking as fixed since Markus' module (http://drupal.org/project/views_fluid_grid) is living on it's own, and working happily with Views :D

...sorry, having this as fixed might give people the wrong impression that this was actually implemented and that the default views module grid format is fluid when it's not.