I have several fields(image title body) in one slide, all fields have fixed height and floating left.

But the slide container seems always set it's own width depending the first field.

How can I stop the slide container to set it's own size and make all elements in slide relative?

I've tried many ways: code hacking, Advanced Options ... all failed

Screenshot-1.png31.71 KBrogical


If someone answered this question it would help me too.

Version:7.x-3.0-alpha1» 7.x-3.x-dev

Moving to dev so it'll show up on my list

This is causing problems for me as well. It's setting the slides' height to the line-height of the body, 24px, which is cutting off most of the slides.

yup. me too!

Priority:Normal» Major

As more people in, may I upgrade the priority to major.

Having the same issue. This issue dramatically impacts responsive theming (web design), as content within slides will not scale to the viewport, causing layouts to break.

Wow. This is a huge issue. Why is that this is not fixed yet? Are you guys really using the latest 3.x dev version? I'm using the latest 2.x stable version and getting the same problem. Help!

Because you haven't provided the patch yet.

I went and removed the div in views-slideshow-cycle-main-frame.tpl.php and that fixed the size issue but of course it also made it so slides didn't rotate anymore. I don't know javascript very well but I'm pretty sure there would need to be some major reworking of views_slideshow_cycle.js in order to get this working right...

A work around
So after thinking for a minute about how I might be able to work around this problem I figured I could create a global: Custom text field with an img of a transparent gif image that is the width that I want for my slideshow (635px wide and 1px high in my case). Sure enough, it works! Obviously not a very good long term solution but if anybody else out there is looking for a work around there ya go!

@maintainer(s) of this module: Are you interested in adding this feature request? If so, how long do you think it would take? I am willing to chip in some $ to get this fixed as it is holding back the release of a couple of my client's sites. If anybody else is interested in chipping in, please chime in and lets get er done!

Status:Active» Needs review

This has been achieved this without using any hack.

Instructions to add advanced features :

1. Created directory called json2 in sites/all/libraries and downloaded https://raw.github.com/douglascrockford/JSON-js/master/json2.js and placed it inside json2.

2. Under FORMAT slideshow settings in the view, scroll "jQuery Cycle Custom Options" and under advance options select containerResize and set the value to 0 > hit "Update Advanced Option". Also add slideResize to 0 > 'Update Advanced Option".

3. Update the view and voila!

Please test if this works for you and report back.

really appreciate!

however, I only set 'slideResize to 0', the 'containerResize' is still needed, otherwise it will break the whole slideshow block.

not sure if this helps either (good practice or bad) but you can always override these values using CSS.

For Example:
#views_slideshow_cycle_teaser_section_[VIEWNAME]-block .views-slideshow-cycle-main-frame-row {
width: 100%; !important

I doubt if you have met the same issue, but the views slideshow would add a inline css height/width to the elements, such as style="...", so any css outside can't override them.

I have met this issue.... when placing !important next to your css attribute it overrides everything from the stylesheet... So it overrides the elements css. Trust me have it working on multiple sites...

@dobe can you provide some URLs for examples?

seems !important is a solution, however, IE6 doesn't support !important.

same problem, it seems that it is taking the width of the browser window upon a reload and the next pause prev buttons also disappear.

before screenshot: http://prntscr.com/2r1v0

reload page and it becomes this:

after screenshot: http://prntscr.com/2r12x

very weird problem. seems like something is being cached as it works fine when you initially land on the page, but messes up on reload.

i fixed it temporarily by adding these:

div.views-field-field-node-gallery-image-fid { text-align:left } -- i had to do this since the container wasnt resizing properly on reload. It seems as if it just stopped in the middle before the code executed to add the inline styles to the element to resize it. default is center.

views_slideshow_singleframe_controls {display:block} - had to do this since the default is hidden. now its just forced to show up.

duckx: have you followed the steps in #11? It works well on several of my sites already.

Re. the inline CSS: this is inserted by the jquery.cycle plugin, which isn't actually part of Views Slideshow. That'll by partly why this module's maintainers aren't able to do much directly about the problem. Google the issue outside Drupal.org, and you'll see lots of people seeking and finding workarounds for the same problem. It's certainly troublesome in these days of flexible and responsive layouts. I'm building a responsive Omega subtheme and so far I've had to add fixed width:xxx !important to each media query - and even so it looks like I'll need some JS jiggery to re-fresh the css when the viewport is resized and triggers a new @media query...

@chibert. This is covered by this module with the use of the jQuery Cycle Custom Options as per comment #11

@nicoz: Awesome. You're right - it works a treat.

I'm having an issue with a responsive layout (also in an Omega sub-theme), and I think it may be related to this discussion.

I've created a slideshow element combining an image, with a semi-transparent overlay containing a headline and some copy. The responsive layout is designed to resize the page layout and slideshow display, depending on the size of the viewport.

It all works fine at a number of different sizes. However, if you view the slideshow with the window at one size, and then resize the window, the layout breaks because the slide is declaring a fixed size. The view corrects itself when the page is refreshed, but the effect is jarring and you can't expect users to know to refresh in order to correct it.

Of course, it's not likely that users will be constantly resizing their windows, but this issue is sort of baked in when users are viewing the page on a tablet device like an iPad. Switching from landscape to portrait display also breaks the view.

I'd like to try the solution suggested in comment #11, but I'm not a developer or programmer, and I'm not quite clear on how to use the javascript code.

Is there any possibility that a fix for this might be rolled into a future release of the Views Slideshow module?

@rggoode: It's not hard to make use of the fix in #11 - just follow the instructions there. Step 1 involves downloading and saving the new json2.js file to the correct location on your server. Steps 2 and 3 refer to changing some (newly available) settings in the View that produces your slideshow. Just edit the view, look for the section headed 'FORMAT', and click the 'settings' link where it says "Format: Slideshow | Settings". Scroll down this dialog until you get to the section called "jQuery Cycle Custom Options" and carry on with the instructions in #11.

I'm using this with a responsive Omega subtheme, and what I did was define css width properties for (in my case) div#views_slideshow_cycle_teaser_section_featured_content-block_1 - different declarations for each of my global, narrow, normal, and wide stylesheets. The fix in #11 means that, when I resize the browser down, the slideshow flawlessly resizes to match. When I resize the browser up, the current slide remains at its previous (narrower) width, but when the next slide loads, it's now the correct size. So: no more browser refresh. Yes, it's a bit odd, but it's no longer 'jarring', and it only lasts until the next slide transitions in.

+1 on rolling this (or something like it) into the Views Slideshow module.

Status:Needs review» Fixed

I think this is best left up to the advanced options. They are there for this reason.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

I could not get the fix in #11 to work. I confirmed that the json and Advanced options were working by setting the timeout to 40000, but slideResize and containerResize affected nothing and still contained the dreaded inline style that made the images unresponsive.

Here's a different fix.

Create a script.js file if you don't have one already and use this:

  // views_slideshow_singleframe_teaser_section

This removes all the inline styles from the class that's giving us trouble. Then just add a couple values in your css (otherwise the slideshow and pager gets out of wack):

.views_slideshow_singleframe_teaser_section { position:relative; height:Your-height-px; }

And yea!

It appears now that I have updated my installation to the solid 3.0 release the fix in #11 (using the advanced options) no longer has an affect on the slide size. It worked perfectly on the dev release (2011-06-27).

#11 - With both or either of those Advanced settings enabled in Views Slideshow 7.x-3.0, it makes the slideshow disappear completely. Not sure why that is after inspecting things with Firebug. The slideshow flashes for a second while the page is loading.

#27 - Doesn't seem to work whatsoever for me when viewing the source code in Firebug.

Any other suggestions or working solutions to try?


Same for me, except it doesn't disappear when I enable one or both advanced settings, when I do enable them, the region collapses and the blocks underneath end up directly under the slider. Take them off ad slider is back to normal.

This is the only thing stopping my site from working very well on different devices. Another method I thought of was disabling the slider completely from the mobile version, the fade effect is crap anyway on a mobile and can hardly see the image text. I might replace with a background image in that region for the mobile.

Still open to suggestions :)


Managed to get the with working ok with resize thanks to post #11 and the following:

.skin-default {
background: url(../images/feature-bg.jpg);
background-position: left bottom;
padding: 10px;
border-radius: 5px;
max-width: 100%;
height: 450px;
.views-slideshow-cycle-main-frame-row {
max-width: 100% !important;

Works ok on my desktop and android phone. However, the obvious problem is setting the height manually like that. As soon as you're on a mobile, you still have a huge height yet the image is a lot smaller.

Thinking of ways to get some sort of container around the whole thing, possibly as display:block and floated to the left.


Ok, solved this fine by simply putting different heights in the different omega stylehseets, one for mobile, one for narrow and one for normal layout. Seems to work ok but I'm not too happy with this as a 'solution', fixed anything is a resposive nightmare.

I can see the need for the fixed 'frame' around the sliding divs but hoping for a better solution which would cover more screen resolutions in a more efficient way.


I got this working fine now (using fixed heights) and

.skin-default {

for the slideshow on mobile, looks crap anyway at that size. Remember though, IE8 does not like 'max-width'! Just use 'width' instead. Hours of frustration getting this slideshow cross browser.


I upgraded to views-7.x-3.0 and found the solution in #11 no longer works! I had to roll back to views-7.x-3.0-rc1...which it works with.
When I upgraded Views, the 'Advanced Options' no longer removed the 'width' and 'height' IMG attributes (they are added added again in views-7.x-3.0).

Does this issue need to be re-opened? Are other people seeing the same issue?


EDIT - I see I'm not the first person, in #28, nicoz, the original poster of the solution in #11, noted having this issue since the release of Views-7.x-3.0


Adding the json containerResize and slideResize doesn't remove the height/width from the images, it removes it from the following div:

<div style="position: relative; width: 940px; height: 353px;" id="views_slideshow_cycle_teaser_section_featured_slider-block" class="views-slideshow-cycle-main-frame views_slideshow_cycle_teaser_section">

into this:

<div style="position: relative;" id="views_slideshow_cycle_teaser_section_featured_slider-block" class="views-slideshow-cycle-main-frame views_slideshow_cycle_teaser_section">

The sizes stay on the images but with the above removed, you can style it out to be responsive :)


Hi Sam,

Sorry, yes you're right and that'd make sense from the naming of the two variables alright. I'm unsure what's happening then, as there are definitely IMG width and height attributes being added now to the image element since I've updated. They definitely weren't there before, so I'm unsure where they're coming from (could even be a module other than views / views_slideshow - imagecache / core!?).

<img width="600" height="450" alt="" src="http://dev.site.com/imagename.png" typeof="foaf:Image">

Have you come across this before or know where they are added off the top of your head? If not, not to worry, I have a jQuery solution in the intrim, adapted from #27.

  // remove all 'views_slideshow_slide' <img> width & height attributes
    $('.views_slideshow_slide img').each(function(){

Thanks again for your help and quick response,

Hi Paul,

The image height/width are added from an image style that I have set in content type slider image.

<img typeof="foaf:Image" src="http://MYSITE/sites/MYSITE/files/styles/slider_image/public/slider/slide-2.png" alt="ALT-HERE" title="TITLE-HERE" height="360" width="960">

I set the image to scale to 960, then scale and crop to 960 x 360. This ensures my slides will be the correct size. My correspsonding css:

img {
max-width: 100%;
.skin-default {
display: block;
max-width: 960px;
height: 370px;
border-radius: 5px;
position: relative;
margin: 0 auto;
.views-slideshow-cycle-main-frame-row {
width: 100% !important; /*works now with IE8*/
height: auto;
background: url(../images/feature-bg.jpg);
background-position: left top;
position: relative;

So it doesn't matter that the height/width is there. My slides scale appropriately as the media query (Omega theme) which is called for narrower screens (iPad etc.) I use this:

.skin-default {
display: block;
max-width: 900px;
height: 285px;
border-radius: 5px;
position: relative;
margin: 0 auto;

which then makes the slideshow narrower. For mobile I then use this:

.skin-default {
display: none

Works like a charm, and the slideshow works in FF, Opera, Safari, Chrome, IE7, IE8, IE9. I only have Windows 7 to test on and a HTC and my wifes iPhone (I set it not to appear on mobile anyway - looks crap at 300px across). The slideshow doesn't resize in IE7/IE8, but nor does the grid system either. Oh when will IE7 and IE8 disappear and never be seen again!!


Hi Sam,

Thanks for such a detailed response!

Ok, great, so you are using the media queries then to manipulate 'skin-default' class, sounds good! The inline styles are read and
injected from here by jQuery then I'm guessing...

Maybe I had modified the 'skin-default' class somewhere previously then I'd say and removed the absolute width x height values
and replaced them with a width percentage (and no height rule/value), so as to avoid using media queries for all images.

When I get a chance again I will try this percentage method to see if it works, otherwise I'll use media queries as you suggest.
Main thing is it works as desired with your method, so I can replicate that! :)

Happy New Years and thank you again,

No probs,

Happy New Year too!


Actually, mine has stopped being responsive!

This code:

<div style="position: relative;" id="views_slideshow_cycle_teaser_section_featured_slider-block" class="views-slideshow-cycle-main-frame views_slideshow_cycle_teaser_section">

has totally disappeared. I have even deleted the json2 folder from the server and still, with it or without it, I get the following:

<div id="views_slideshow_cycle_teaser_section_featured_slider-block" class="views-slideshow-cycle-main-frame views_slideshow_cycle_teaser_section">

There is no position:relative anymore. I think I updated views from rc1, but now I think I need to modify my css again. With json2, not all the effects work, see my post here:


And without it, I can't seem to get it to resize properly. Obviously doing something wrong but all is not happy in my camp right now!


If anyone is still interested in this, I have created a feature that makes views slideshow responsive and also incorporates client-side adaptive images. See http://drupal.org/sandbox/nicoz/1538528

I plan to release it soon, but would love a few testers to provide some feedback.

Comment moved to the Bendy Project issue log.

I just used Post 11 and added width to 100% to the advanced options settings and it worked great.

Are you sure you've managed to set the width in percentages. When I change the width to 75% at the advanced settings tab, it just reads it as 75px.

For what it's worth, I was also getting this issue. However, since my image had a height being inherited as well, I just set the following.

.foo {
    width: 100% !important;
    height: auto !important;

A combination of #11 and the following jQuery helped me out:

$(window).bind('resize', function() {

When I would resize the browser, it wouldn't resize the hard-set containing div. This fixes that.

I'm still having some trouble with numerous attempts to fix it.

I'm using the Omega HTML5 theme with the responsive layout and I can get the slideshow to display perfectly on load. When I resize the browser after the slideshow has loaded, the images in the slideshow will shrink by using max-width css. I need the main frame to resize too as I have a css3 gradient on the zone-wrapper that the slideshow sits in.

I am happy for it to work responsive as I don't think many users will resize their browser after the slideshow has loaded, but I still am hoping to find a long-term fix as I have multiple Drupal installations using Views Slideshow.

Here is the CSS that I have tried using:

.views_slideshow_cycle_main {
width: 100%;
.views_slideshow_cycle_main .views-slideshow-cycle-main-frame {
width: 100% !important;
height: auto;
.views_slideshow_cycle_main .views-slideshow-cycle-main-frame-row {
width: 100% !important;
height: auto;
.views_slideshow_cycle_main .field-content {
max-width: 100%;
width: 100%;
.views_slideshow_cycle_main .field-content img {
max-width: 100%;
width: 100%;
height: auto;
margin: 0;
padding: 0;

Post #11; When I set the slideResize to 0, it doesn't seem to change much if anything for me.
If I set both slideResize and containerResize to 0, it will break the height of the block (0px).

I have tried adding the script in post #46 but didn't notice a difference.

I was having the same problem on one site (yet somehow not on another) and I used the following, found in this post: http://drupal.org/node/1611744#comment-6750736

.views_slideshow_cycle_main .views_slideshow_slide {
width: 100% !important;

For people wanting a proper responsive solution follow this issue and try the sandbox #1801332: Support Malsup's Cycle2 Plugin

#48 worked for me! Thanks!

Easiest good solution (these little css tricks won't work in all situations) currently is to use the flexslider module, which adds a new views slideshow type that works out fo the box.

Listen to rooby everyone, I have found this to be the best solution. And it does work out of the box with no difficulty in combining with views slideshow.


#47 worked like a charm, thank you!

This puts me in the right direction .
but only resizes the first slide.
other slides content go out of the block.

Keeping track of this.

For those that are still trying to hack away at making views slideshow responsive try using something like Flexslider http://drupal.org/project/flexslider or Views Slideshow Liquid Slider http://drupal.org/project/views_slideshow_liquid_slider instead. View slideshow, more specifically jquery cycle 1, was built well before responsive design was even a "thing". You are going to find that it takes hack upon hack just to get something that eventually is just sort of responsive. When views slideshow leverages jquery cycle 2 http://jquery.malsup.com/cycle2/, then we will be laughing. Until then, do yourself a favor and use a module and a library that was built from the ground up to support responsive designs. See #1801332: Support Malsup's Cycle2 Plugin for more info.

I am using #47 for now until cycle 2 plugin is more stable and a real release is available.

My two cents on this thread...

Recently, I have been working on a new project that has a slideshow. It has a particular requirement and normally using Views Slideshow is not an issue -- it just does 99% of what slideshows do. Yet, it isn't currently responsive using the older Cycle javascript library.

I thought, no bother. I have used Flexslider and Nivo before, why not try those. Off I went and discovered that they don't have as much flexibility nor features. But, wait... what? Responsive should be easy! Uhh, what is this... thumbnails and/or pagers are a little harder to make happen for those projects? What? Really? Where are the features I am used to with Views Slideshow? This one isn't responsive when the document says it should be? Huh?

Thus, having run the gauntlet of every single slideshow module over the last week and a half -- NONE of them come close to the flexibility of Views Slideshow itself (using Cycle). They may be responsive (oh, but wait!) but they all lack features like custom pager support (all of them), animation support (Flexslider), responsiveness (Nivo), or they may barely work (Liquid). They all feel unfinished (Liquid is very hard to get working and I don't think the module is finished).

Is this their fault? Hardly. They are newer. They are being built. It isn't their fault that they don't have a huge number of hours behind them by a large group of people who donated their time.

I don't want to sound like an ungrateful jackass but I have many, many years of experience with Drupal and even I was very surprised that the other modules being developed are not as functional as Views Slideshow. I am almost at the point of apologizing to anyone who is new to building slideshows right now. If someone wants a quick slideshow, Flex/Nivo/Liquid will suit them fine. But get into customization and you start to see where these other modules break down.

Of course, I don't want to belittle the contributions of those who have worked hard on the various slideshow modules currently available but I think the end user is getting a little shafted who are very much beginning their builds or learning how Drupal works. The "simple" process of making a slideshow on their site is a nightmare if responsive designs are in play.

Anyway... I had to vent somewhere and this is as good a place as any. If I am running into trouble, I can't imagine what new builders may experience. We're all in this together and I feel like will have let the community down somewhere by not commenting on my experience.

That post doesn't really seem useful to anyone. Plus it is in an issue marked as closed so a lot of people won't even see it.

You mention elsewhere that you are willing to pay for someone to develop what you need to maybe just say what you need and that you are willing to pay someone and maybe someone will contact you about it, but there are no guarantees.

Also try the https://drupal.org/paid-services area or try directly contacting companies that do drupal development.

Issue queue's aren't really a reliable place to get things done fast if you need features fast.

Hi @Shane Birley,

As an attempt to move things forward, I've already sent you a private message directly to discuss further any potential work to #1801332: Support Malsup's Cycle2 Plugin.
Let's hope something positive and constructive may come out of that for you and the community.

Thanks again very much for your support and involvement in the Drupal community.

Hey, @rooby!

All of this I already know... I partly vented on this thread because it was closed. I was merely wanting to vent somewhere because I was shocked at the current situation for site builders in regards to slideshows. As a community, we've covered most situations but in terms of flexibility and customization there is some work to to.

I also want to make sure that anyone who reads my rant, that it is just that -- a rant. We all feel from time to time that we can do better as a community and I am pointing the finger at myself. I have been using Views Slideshow for a very long time and have bounced in and out of the issue queue here and there but I didn't notice until the last week or so that Cycle2 (which was released more than a year ago) hasn't been fully introduced.

I have been using Drupal since version 3.x (closing in on 10 years) and I have written documentation, run training boot camps, committed several modules into the community, and helped to debug stuff - but even us hard core users find areas where we personally could have done better. I should have offered to help out six months ago. I should have helped to commit something a year ago to get the ball rolling. I should have helped to debug things when the sandbox was created by @Ben Young and helped out to integrate the new library in any way I could.

It makes me feel guilty, that's all. I want to help people succeed in their site builds but, in this case, I can understand how people without as much experience with Drupal as I have may feel and it pains me that I failed in some way.

Yet, when people rant publically, it comes across as... uhh, wanker-ish?

Hey, @DYdave!

I will ping you back in a little bit.

I am not exactly sure what your issue is with the views slideshow.. I know you mention responsiveness.. I have been working with the views slide show a lot and have managed to make it responsive with overrides within the CSS itself.


The main issue is not widths on images, it is usually when there are other elements working with imagery. For example, in one case. I have a slideshow that runs with only a single image on the slideshow stage. It fades/slides quite happily.

But the other situation I have run into is when you add in pagers and other things below. The current Cycle library is not awesome at dealing with heights because the heights break apart if there is more than just a single item within the context of the whole slideshow.

Does that make sense?


With cycle v1 + views slideshow I can pretty much guarantee that it is not possible to make it responsive once you have more complex slides.

I've tried all manner of css + js hacks and there are always issues.


I have been in contact with @DYdave and am trying to put together a budget to get the code from the sandbox reviewed and finish a proper implementation of Cycle2 into Views Slideshow.

If you know of any more people with money that want to help, let me know.


I'm more of a flexslider user these days but I can help with testing once there is something to test.

Previously I wouldn't use the cycle2 sandbox because it required jquery update, which was very buggy at the time.

Now that jquery update is less buggy I would say it is a much better proposition.

@ Shane, Yes you are right, it does make sense, and doing the CSS hacks is a lot of work. About the heights, I had to force height definitions on most of my elements as well to get things to work properly.