Just wondered if anyone using the Flexslider has found that when switching back and forth from different size browser windows the slide images do not automatically adjust to new height and widths.
Let me clarify - they do shrink correctly but when scaling back up the first image in the slideshow gets stuck at the previous aspect ratio until the next slide comes in, at which point the whole thing adjusts.
To stop my content from being affected I have created a fixed height container for the flexslider and have used media queries to change its height as it is scaled down. This works perfectly scaling down.
It seems to be on the way back up that it has trouble sorting the image heights out.
I would provide links but it is a new client project in confidence.
All coding is exactly as is from the demo files, with exception to the fixed height and media queries on the container div.
I had the SAME problem - I found that not all my widths were of the same value.
e.g.
.clone { display: block; float: left; width: 994px!important; }
<img src="http://www.website.com/images/panel1.jpg" alt="" width="980px">
There were about 4 instances in my css that had different widths [shame shame] so I went in there and raked the css file.
I hope this helps
Good Luck
Related
I've been working on a new responsive website design and I have a gallery containing a grid of images which when the browser viewport is 768px or above spans 4 columns wide (so each image is about 25% of the viewport). Anything 767px or lower is only 1 column wide (making it full width at lesser resolutions).
The images at desktop size (over 768px) should be 220px wide (4 image columns).
Between 480px and 767px should be upto 420px wide (1 image column).
And mobile size (under 479px) should be upto 260px wide (1 image column).
I have three sources for each image. 220px, 260px and 420px.
As you can see from the above, the sizes don't follow the normal conventions of the smaller the viewport the smaller the image, so I've been researching and trying various options.
Following suggestions, I've been using Google Chrome in incognito mode and also inprivate browsing for internet explorer, with the browser viewports started small before loading the page, etc... to ensure any changes I've been making get updated.
The current code I've come to is the closest I've got to making it work and it is following an answer to someone's query (similar to mine) here on stack overflow. However, when trying to implement it I can't seem to get the browser to load the right images still, it always loads the larger 420px wide image.
my code is currently like so:
<img sizes="(min-width: 767px) 420px, 100vm"
srcset="images/thumbs/image_420.jpg 420w,
images/thumbs/image_260.jpg 260w,
images/thumbs/image_220.jpg 220w"
src="images/thumbs/image_220.jpg"
alt="example image"
/>
A second query whilst I'm on the subject. Would it be best to set the default img src in my scenario to the 260px image? As this would cover both desktop and mobile browsers in the event the srcset isn't understood and only the middle sized viewport (460-767px) would suffer. Or is it always best to set the default image to the smallest size?
Any suggestions would be appreciated, thank you.
-- EDIT --
Just a quick update, I thought I'd logically figured it out yesterday but it didn't work so I'm not sure I still understand the whole concept of the calculations. My latest edit looks like so:
<img sizes="(min-width: 460px) 420px, (min-width: 768px) 220px, 100vm"
srcset="images/thumbs/image_420.jpg 420w,
images/thumbs/image_260.jpg 260w,
images/thumbs/image_220.jpg 220w"
src="images/thumbs/image_260.jpg"
alt="example image"
/>
So in my mind I think that the sizes section I've listed states... if viewport is at least 460px then use the 420px image, else if viewport is at least 768px use the 260px image. Then the last 100vm means otherwise use whichever is best at full viewport width.
I've also amended the default file to be the 260px file as this fits most of the viewport sizes if something hasn't been recognised.
However, the above edit still loads only the 420px image.
Any suggestions would be very appreciated. Even if its just to correct my logic!
sizes is evaluated left-to-right. So the order is important. If the viewport is 1000px, then the first media condition (min-width: 460px) will match, and so that size 420px is chosen, and the rest of the sizes attribute is not evaluated at all.
Also, the unit should be vw, not vm.
So it should be:
<img sizes="(min-width: 768px) 220px, (min-width: 460px) 420px, 100vw"
srcset="images/thumbs/image_420.jpg 420w,
images/thumbs/image_260.jpg 260w,
images/thumbs/image_220.jpg 220w"
src="images/thumbs/image_260.jpg"
alt="example image"
/>
As for your second query, technically you can choose any image you like (even one not listed in srcset), but your reasoning makes sense to me. The only thing I would recommend is to put your chosen src image first in srcset, because older WebKit with partial x-only srcset implementation will pick the first item when it doesn't understand the descriptors.
I've been trying to find/prevent why my page is freezing at Firefox, I'm using Chrome's Developer Timeline to track the layouts and paints (freezing doesn't occur at Chrome, a huge issue at Firefox with ~300 UI tiles on the page)
It's understandable that gifs cause paints at each frame (a much much larger paint area than the gif itself, unfortunately) - however I don't understand why Chrome reports a "whole document" layout before each frame - since the size of the gif is constant, it should only cause paints in my opinion
I'm guessing these "whole document" layouts are causing firefox to freeze when there are many elements on the document
(I've researched reflows/layouts, repaints in depth, however none of the articles cover gifs, by looking at the timeline, I would say gifs are major resource hogs)
After more careful inspection and testing, I was able to prevent full document layouts by utilizing a gif container div, such as:
<div style="position: absolute; right: 0px; top: 10px; width: 45px; height: 15px; overflow: hidden">
<img src="/gif_url" style="vertical-align: top"/>
</div>
The issue was probably occurring because of the gif's positioning, happens with both float:right and position: absolute, even when the img element has fixed height and width of it's own (might happen with other positioning styles too)
I didn't dive into the issue too deeply to see what triggers the full document layouts and what not, however, it seems like a good idea to wrap every gif with a blocker div to be sure that browsers calculate partial layouts (I'm guessing there might be a combination of styles that might be able to achieve this inline, but I haven't pushed it yet)
- EDIT (after much inspection) -
It turns out the root cause is Bootstrap 2.3.2's default "max-width: 100%" style for img's
Removing that definition seized layouts caused by gifs
If there is going to be even one gif on the page, that style should definitely be removed / cancelled - otherwise at each gif frame the whole document is being laid out by the browser (chrome in this case, possibly others too)
I would be very grateful for some help with a Safari image resizing issue as I have spent three days on this one problem.
I am building a responsive store with Woo Commerce using the Canvas template.
The problem is with the Safari browser...it won't enlarge the images to fit their container div and be evenly spaced and sized.
Here is a category page for your reference: http://omshivaloka.x-gr.net/product-category/shop/men-2/men-malas/
Here is a single product page, with the issue at the bottom beneath: "Products you may like": http://omshivaloka.x-gr.net/shop/hanuman/
I researched extensively all over the internet to find a solution and keep hearing to change the height and width in my CSS to:
ul.products li.product a img {
height: 100%!important;
width: 100%!important;
}
It's making them stretch, and is therefore not a solution.
In my Woo Commerce configuration, I have set the size of that picture to be 210*300px - Safari is not recognizing that...or maybe it is and is not outputting it immediately?
Perhaps you are having the same experience as I am in seeing the image expand when you mouse over it. Strange indeed...
I appreciate any help...thank you!
Cassandra
I've got a really simple page which uses a photo as a full-screen background. I'm using the following to define it:
body {
background-image: url('../Images/Backgrounds/Hillside.jpg') ;
background-size: cover;
margin: 0px;
}
The image, obviously, takes a little while to load after changing page so I've implemented a noddy jQuery $.load() to update the content without the overhead of a full page reload.
Unfortunately, firefox seems to have an issue when the new content causes the length of the page to change. Firefox correctly realises that the scale of the background image has to change and repaints the page behind the content div appropriately - but doesn't repaint the rest of the page - hence it looks like 2 differently scaled images are overlaid.
Resizing the window or causing a repaint fixes it. Unfortunately, I can't take a screenshot as it never shows the problem - presumably it does a repaint behind the scenes.
To demonstrate the problem, visit the site, shrink your browser window so that content forces a scrollbar. Change URL using the menu. Look at the image behind the main content in comparison to the rest of the page (About us and Sample Ads are long pages, contact us/prices are short).
How can I force firefox to do a full repaint? I suppose I'm looking for the equivalent of WinForm's Me.Invalidate(). Is there a better way to do the background image?
NB: I've shrunk/degraded the photo to reduce file size but haven't spent a lot of time on it yet - I know it can be much better.
Edit:
Environment: FF9.0.1 Win7 Ultimate x64.
Steps to reproduce:
Browse here
Resize the window so that the white content area is just above the bottom of the browser window (Also, it's handy to make sure you can see some land in the background to make the effect more obvious)
Click on the "Sample Ads" link
Click back and forth between Sizes & Prices/Sample Ads
As you do so, you'll notice that anything to the right of the menu doesn't scale but the image under the menu/content does.
There are two solutions I got.
The first is simply on loading new content do the following:
document.body.backgroundSize = 'auto';
document.body.backgroundSize = 'cover';
Just tells it to recalculate the cover area.
The second is very hacky and literally just tells FF to reapply all the styles.
for(var ss = 0, len = document.styleSheets.length; ss < len; ss++) {
document.styleSheets[ss].disabled = true;
document.styleSheets[ss].disabled = false;
}
That said, I would also report this as a bug to FF (if you haven't already or if it does not exist in the system).
I see a problem which probably attributes to your issue. Add this to your stylehseet:
html, body {min-height:100%;}
You see, background-size:cover; is only covering the body's physical dimensions. Let's say your body is actually only 400px with its content, but your window has 1000px of height. The browser first applies background-size:cover; which it does so for the 400px tall body, then it sees there's 600px more of space in the window, and kindly applies the background further; in this case, tiling/repeating it. By giving the html/body a min-height of 100%, as above, your body will always fill the available height.
I added a box-shadow to a section of a page recently to give it the same shadow border effect that is seen on Mac OS X apps. It looked great, but I noticed that scrolling up and down on the page made it lag. I usually only see this on pages that have annoying background images and tons of images and embedded videos plastered all over (cough MySpace cough). I originally decided to use box-shadow since I figured that it would remove the need to use an image, which would remove any possibility of scroll lag.
I know that CSS3 is still new, but is this the reason for the lag? Is the shadow being software rendered or something? When I apply the box shadow to smaller elements, it doesn't lag at all. I'm just wondering if anyone else has experienced this.
I just tried it on the Stack Overflow front page, on the #content div using Firebug with a setting of:
-moz-box-shadow: 1px 1px 10px;
And I did notice some scroll lag afterwards. I am using Firefox 3.5.
My question is, what are some alternatives to using this attribute if I want to add a Mac OS X style border to a section of my page?
On a side note, does anyone know if it is possible to apply the box shadow only to the top, left, and right sides of the element and not the bottom? I tried 1px -1px 10px but it still shows the shadow on the bottom. If I keep decreasing the second offset, it eventually removes the shadow from the bottom but then the top shadow is now way darker and bigger.
And yes, I have seen the articles on box-shadow at:
CSS3 Info
fredericiana's blog
Your best bet would be to use -moz-border-image instead. That should solve both your issues.
E.g. you could use an image like this,
, combined with CSS like this
-moz-border-image: url(shadow.png) 10 / 10px;
to create your shadow. And since you're using an image, you can leave out the bottom shadow as well, if you want.
You're not going to be able to remove the shadow from the bottom using -moz-box-shadow; it's not called "box shadow" for nothing. It applies a shadow to the entire box. You can't specify a shadow for each side separately like with border, say. The best you could do is fiddle around with the placement, blur and spread of the shadow. But that inevitably leads to a darker shadow on the opposite side.
I get the box shadow lag as well when I try it on Stackoverflow. It affects performance on Safari as well when I try -webkit-box-shadow, though it isn't as noticeable as in Firefox. The performance will hopefully improve in the future, but I presume the shadow will always have some impact since as far as I know it is software rendered.
This has been fixed in webkit as of two days ago. :)
https://bugs.webkit.org/show_bug.cgi?id=22102
You can pick up a chromium nightly to try it out.
I looked in FF3.6 and FF4 and don't see terrible scroll performance there, so it might be addressed there as well.
The issue still persists in Chrome for Android as of the current date. Some box-shadow combos result in a poor scrolling performance. In my case stacking two inset box-shadows (e.g. top / bottom) lead to the described problem. The only solution I can provide is to make the box-shadows less complex and try again...that worked for me. That's unsatisfactory but yeah instead u can also use the border-image solution or remove the affected box-shadow completely. Hope this gets fixed soon, finally. Btw the Android Version of Firefox does not have the problems anymore (for my css3). Moreover the desktop versions of both browsers are not affected in my case.
#shadow {
-moz-border-image: url(img.png) 10 / 10px; #Firefox under v15.0#
-webkit-border-image: url(img.png) 10 / 10px; #Safari, Chrome under v15.0, Android & iOS#
-o-border-image: url(img.png) 10 / 10px; #Opera under v15.0#
border-image: url(img.png) 10 / 10px; #IE v11+, other new Browser#
}
Cross browser version for old and new browser.
Simple img: http://i28.tinypic.com/2njzkt1.png
style :fixed for images too overload perfomance browser