We are having some problems finding the source of background images not loading. As far as we know there have been no troubles with them loading prior to implementing eu cookie javascript function.
jsFiddle: (just the JS) http://jsfiddle.net/dx4MC/
For some reason, on occasions we cannot replicate (appears to be random) all background-images on a page will fail to load. Has anyone come across this before?
A possible thought was the js wasnt allowing the CSS to load fully, however no other styles have been affected, only the background images.
try using
!important
in your css to override the javascript inline styling
Related
I've been working with some basic animations lately and trying to follow good web practices at the same time. The problem I'm encountering is image flicker when not using a preset css method to hide the element before the page loads.
It's very easy to prevent the flicker by just hiding the element with my normal css and then revealing it with javascript, but that seems to me a horrible practice if someone has javascript disabled.
Should I use the HTML5 feature of putting <noscript> tags in the header and then use a separate style sheet to set the opacity and position to the final settings for users without javascript? Is that the most elegant solution?
I've started using the greensock (gsap) library to TweenLite.from, since I can just set everything to the final state in the css, but I get a slight image/text flicker the first time the page is loaded. I like this solution because I can set all of the css as it will be for someone with no javascript, and it allows me to easily animate from a point, to an existing point, instead of working backwards like I have to do with Javascript or jQuery. But, there's still that image flicker which isn't really acceptable. Would a page preloader solve this?
What is the generally agreed upon practice for this these days? I'm also worried about SEO and the consequences of setting stuff to visibility: hidden or display:none and then animating it in. Does the Google spider read javascript?
Here's an example of the screen flicker and animations I'm talking about.
Have a look at HTML5 Boilerplate and Modernizr.
http://html5boilerplate.com/
http://modernizr.com/
It ships with a smart solution to see if a client has JavaScript enabled in CSS.
By default a class no-js is applied to HTML tag and it is then replaced by js by Modernizr. That way you can qualify your CSS selectors accordingly.
Example CSS:
.no-js .foo { }
.js .foo { }
This should execute fast enough that clients with enabled JavaScript don't see the no-js styles.
References:
What is the purpose of the HTML "no-js" class?
https://github.com/Modernizr/Modernizr/blob/master/src/setClasses.js#L9
Does Bootstrap "Carousel" load all images at one time? If so, does it reduce site loading speed and increase loading time?
I do not know how Bootstrap Carousel javascript file works. When next icon is clicked, if next image is loaded via ajax, there is no problem. But if all images are loaded at one time, I think it reduces page speed.
Any idea?
Bootstrap carousel just rotates it's items. If images are defined by src attribute, images will be loaded with the rest of the page.
You can use some lazy loading solutions to load images sequentially - Google search
Bootstrap does not do any magic lazy loading behind the scenes as Tigran points out. However, many browsers do not request images that are hidden through "display:none". So when inspecting network traffic with, for example the Chrome browser, you will see that the images are in practice "lazily" loaded.
An outdated and almost unreadable list of browsers with this behaviour can be found here: http://www.w3.org/2009/03/image-display-none/results
I'm running a function on every keyboard keyup to monitor a text field.
Depending on the input, I am using jquery to .removeClass("classwithBGImage").addClass("classwithnewBGimage")
This is working nicely, expect on the first load there is a flicker in the background image.
I have tried preloading the images with Javascript and CSS, even tried using a sprite - but there is always a flicker on the first load when .removeClass("classwithBGImage").addClass("classwithnewBGimage") is triggered.
Update:
Seems to be a documented chrome bug:
http://code.google.com/p/chromium/issues/detail?id=102706
As witnessed in this jsfiddle: http://jsfiddle.net/QpvUQ/2/
Any ideas? Much appreciated.
Apply the background-image to a div positioned absolutely and left:-99999px.
#preload{
background-image : url(large-image.png);
position:absolute;
left:-99999px;
}
Later, use it for the actual div
.classwithnewBGimage{
background-image : url(large-image.png);
}
This is one of the hacks that I am aware of for pre-loading images so that they don't take time when you actually use them.
Also, .removeClass() without arguments does nothing. To avoid flickers use smooth transitioning.
.stylesWithoutImage{
///
}
.classwithnewBGimage{
//img
}
Using Move.js you can Animate CSS Changes.
move('.box')
.set('background-image', 'url(img)')
.end();
PS : Not tried but it say's you can animate CSS with it.
I did an implementation with only CSS to do the same than your jsfiddle.
How it works?
.class {
background: url(...);
}
.class:hover {
background: url(...);
}
I left the JS code if you need to do it with Javascript, but with only CSS should be enought.
http://jsfiddle.net/QpvUQ/7/
I've figured out the problem in case anyone else runs into the same issue.
With preloading, the images are preloaded but many browsers still receive a 304 response for the image causing a flicker on first load. You can force the browser to cache images in the case with rails applications.
Enable image caching in development mode in Rails 3.1
I've developed a JS-heavy site using the Mootools library and have hit a bump in the road. There is a scrolling div on the page that contains 500+ images and I'm trying to implement a lazyload feature so the page doesn't load all 500+ images at once.
I found David Walsh's lazyload class but it doesn't work in webkit browsers (he says this is because of WebKit bug #6656).
I also found this class and it appears to work but doesn't really. It still loads all images on the page but hides the images outside of the viewport and fades them in when scrolled into view.
There seem to be a number of jQuery lazyload classes that work really well (in all browsers), but I'm already weeks into the development of this site and can't really justify switching for this or using two libraries.
Anyone know if there is a Mootools lazyload class out there that works in webkit browsers? If not, have any recommendations? Do I have to resort to using jQuery alongside Mootools?
This issue is holding development up a bit.
You could wrap the images inside of a noscript tag. Browsers won't load images inside of there if you have Javascript enabled. The nice thing about it is that it degrades well for non-JS browsers. I describe in more detail here:
http://experimentsbykevin.tumblr.com/post/754769738/lazy-image-loading
Are there any differences in performance or load/caching behavior when displaying images in img tags vs divs with image backgrounds?
My example:
I have a site with many overlapping images, some of which I will need to load dynamically with javascript. One issue is that I need to anchor the images to the right of the element, so that I can do a nice wipe-to-right effect. Because of this I was using a div with background image positioned right. Couldn't figure out how to do this with img but since divs are working for me I didn't know if this would matter...
AFAIK, browsers cache images the same whether they're in a DIV or an IMG. In any case, I think this one of those cases where specific performance is defined as an implementation detail internal to each rendering engine (and possibly the browsers built around them). As such, it's both out of our control as designers/developers and subject to change from browser to browser and version to version. In other words, I wouldn't spend too much time worrying about it.
The main performance difference is using background images allows you to use CSS sprites. Having one image contain a large number of images from your page means the user only has to make one request instead of one for each image.
Another difference is with responsive layouts. If you have an element that is only shown at certain screen widths (ie, not on mobile phones), it will still load the image if it is specified in the html (using display:none for instance), but most all browsers now will NOT load the image if is a background-image specified in unused media query-CSS rules. A lot of early responsive layouts got criticized because they still used the same bandwidth as the full size sites.
It is also useful with such designs because you can easily specify different images for different screen sizes. "Retina" displays on tablets and even laptops now won't look their best without 2x res graphics. So... even if you don't do such things now, it is probably a good practice to get into, because you might find yourself needing it soon!
I think by using background-image attribute in the div, the page layout gets loaded first and image present in the divs loaded later after the dom is loaded. so by using background-image the html layout is loaded faster on the web browser.
The only difference I can conceive of it this:
You can't scale images as backgrounds, although you can for img tags. This would open a scenario where background images loaded faster becuase it forces you to have the correct native size as opposed to downloading the entire image and scaling it. However, the converse could be true: given that you didn't care about image quality so much, you could deliver smaller imgs to your page and scale them up.
I'd stick with whatever rendered cleaner (and more consistently -- IE/FF/Chrome/Safari/etc).
Technical differences yes, most notably you can set the width/height of an IMG tag and it will stretch the image, which can be useful in some situations.
The main thing you've got to keep in mind though is the context of the image within the HTML document. If the image is content, say an image in a gallery, I'd use a IMG tag. If it is just part of the interface I might use a div instead.