We discussed this topic with colleagues... Is it better to hide/show or add/remove GIF loader in HTML using JavaScript? We came to this:
Hide/show pros:
showing the loader does not require its creation using JavaScript so it should be faster; Is negligible?
is simpler
GIF picture is readily available
Add/remove pros:
removing the loader (thus DOM element) should speed up querying/working with DOM elements
if your site has a lot of loaders, it is possibly slower to download; Can negate using HTML5 Application Cache?
lazy loading - GIF picture needs to be downloaded only if it is necessary
Are there more pros/cons? How do you work with GIF loaders? Which technique do you recommend? Lets assume two scenarios:
There are multiple loaders on the page...
a.) using a single GIF picture
b.) using more GIF pictures
In my experience, hide and show is a better approach because it doesn't mess with the DOM. There probably isn't any performance benefits but if you remove it from the DOM and then re-add it later it is possible to lose JS event bindings unless using jQuery's .on() event handler.
May I also add that while GIFs are a long supported feature of most browsers, CSS animations can create much smoother loading indicators and have smaller file sizes, too.
The answer is, there is no easy answer to your solution. Is it a simple web app? is it a HUGE application that needs to have an animated gif attached to it to load?
If you have a larger application:
simply preload the animated gif (either using modenizr.js or css) and then you can simply make it the background of a div that you can append to anything at any time and remove it gracefully. (extremely fast, saves memory). the downside is that if you are not very experienced chances are you might forget to remove it correctly.
in your css
.loading{height:100px;width:100px;background-image:url(loader.gif);background-position:center center;}
this is now your "loading div" and css will load the background image into memory.
next
what ever ajax div you have (lets assume it is #content)
$("#content").append("<div class='loading'></div");
then whenever you want to get rid of it ( probably on the ajax return call)
$('.loading').remove();
I think this piece of coding resolve the problem:
$(window).load(function() {
$("#loader").remove(); //call the image with id like #loader
});
Related
This is largely a theoretical question, for which I do have a practical purpose. I first am looking for some conceptual answers before diving into practice, as perhaps the idea itself does not make sense.
Imagine a slideshow that is entirely javascript-based. Users see a large image on their screen and click to move to the next large image. Upon clicking, the next image is loaded and inserted into the DOM, replacing the previous one.
I recently learned that prefetching directives can help in speeding up the loading of resources that are very likely to be used next. Note that I said resources, not pages. The slideshow is a single page.
In an image slideshow, it is very obvious that it is likely that the next image is needed, thus if image1 is on screen, I could dynamically add this to the DOM:
<link rel="prefetch" href="http://img.mysite.com/img2.jpg">
My questions regarding this idea:
Would it work at all? Do browsers accept this directive when it is dynamically inserted in the DOM at run-time? Would it trigger the prefetch?
Is there a possibility of timing conflicts, where if prefetching would indeed work, it did not finish in time before the use does the "load" without prefetching? Obviously this can happen, but will it have unwanted side effects?
Will specific events such as image onload still work correctly, or are they never triggered in the case of a successful prefetch (assuming it works at all)?
I did a lot of searching but I am unable to find answers on this specific situation of dynamically injected prefetch hints.
onload always gets triggered, even if the image is coming from cache. You do not have to worry about timing effects or race conditions, any such behavior would be a browser bug.
As mentioned in comments, rel=prefetch is not the only way of achieving pre-fetching. It works though even when dynamically inserted into the DOM. After all, you could fetch the image without the prefetch attribute and hide it.
I've got a site where I need to load JavaScript and CSS files dynamically through AJAX. I've got this working fine, my issue is with loading this content into the DOM, specifically the speed.
In desktop browsers, there's no performance issue. But on mobile browsers (the site is aimed at phones/tablets), there's a good second or two of lag between the script/styles being downloaded and finishing processing.
Originally, I was creating a new script/style element, appending the retrieved data and appending the element to the DOM (the 'head' node).
Then I tried using 'document.write' to write a script/style tag with the content into the page (this is how Bing/Google do it on their mobile site).
Both of these methods are too slow.
Is this likely to be due to the size of the scripts needing to be processed (70KB of JavaScript. 65KB of CSS)? Or is it to do with how I'm inserting in into the page?
I've not seen any tutorials/blog posts on this that mention a speed issue, but I've not seen any that are specifically for mobile.
I think the size is a problem here. Have you try to compress : http://closure-compiler.appspot.com/home
Does the lag happen once or multiples times ?
I'm for years using something like this in my HTML for elements which should be hidden:
<div style="display: none"></div>
It's ok, but I can't stand in-line styles anymore.
Hiding elements programatically in JavaScript window.onload event is too late -- it will flash on the screen.
I can create CSS class 'hidden', but with browser's aggressive loading strategies (like in Opera) the block may appear for a second (before CSS is loaded).
Is there any better way?
As far as I know the class="hidden" method is the best and most commonly used. I suggest you use class="hidden".
"but with browser's aggressive loading strategies (like in Opera) the block may appear for a second (before CSS is loaded)."
I don't use Opera, but if any browser loaded the page before applying styles then a lot would look wrong, not just your hidden elements. I don't know of any browser doing this.
I have recently started using node objects, and I like this approach more and more. This way you don't have to use hidden HTML elements, you just place, for example, an anchor:
<a name="some-anchor" id="some-anchor-id" />
and then replace it with a created node. This way you won't have to worry about elements flickering on load, because there won't be any.
Depending on what the element is, it might be acceptable to generate and insert the element using javascript after the page has loaded (rather than hiding it after page load). Just a thought, although it wouldn't degrade gracefully for users without javascript enabled...
You could add to the hidden style a fixed position which would bring it out of a browsers window. This may be a solution to avoid having the div blink in Opera.
For example:
.super_hide{
position:fixed;
top:-1000px; /* you would need to know how height the content is or put something huge*/
}
Hoping this will help!
If you have a HTML only page those elements would be shown?
These elements are shown to screen readers by default, that's not very nice or accessible is it?
If you have HTML+CSS only page you can't unhide these elements, then there's no point in them apart from black hat SEO tricks.
If you have a HTML+CSS+JS page then there is value in have them.
There is only value in having them when you have JS enabled. This means they should _exist in the javascript
Use javascript to create these elements and inject them in the DOM.
if your build your website from the ground up using HTML, HTML+CSS, HTML+CSS+JS then you would realize they belong in your javascript code. Feel free to read more about Progressive Enhancement
You could define the class in of the page. It's slightly cleaner than inline, but you would have to have that single class definition on all pages. But then again, I'd try to use a single dynamic footer/header anyway..
I've published a website and every page has an or element with Cufon (cufon-yui.js) and sometimes while the page is loading , the visitor can see the text replacement tool doing it's job. It looks bad, some users are asking about it.
Why would that be happening if I'm using it (cufon) like anybody else and I don't' see this text rendering issue happening in most sites.
Also, there's an issue happening as well, with the Hyperlinks that are using Cufon.
Sometimes the cursor (a hand that appears for hyperlinks) disappear , it's bizarre.
Adding the following to your css should solve the issue:
.cufon-loading {
visibility: hidden;
}
use one of the google web fonts or typeface/
I've just started looking at Cufon, so I'm not sure I'm qualified to give an opinion, but I've read the IE has (or had) rendering issues and that you needed to add <script type="text/javascript">Cufon.now();</script> to the end of your body (right before the </body>. If you are running any other heavy scripts on the page, you might want to put them as low on the page as possible and place the Cufon.now() right above those scripts (place Cufon higher in priority). If that doesn't work, try hiding your Cufon elements with JS as soon as the DOM has loaded (visibility:hidden) and then unhide them when the onload event fires (though I'm not sure that's much better than the text flickering).
Use something better?: http://reisio.com/examples/webfonts/
(if you worry about distribution legality, replace your fonts with any of the numerous free clones available all over the internet)
I'm developing sites using progressive enhancement implemented completely in jQuery.
For instance, I'm adding onclick event handlers dynamically to anchor tags to play linked MP3 files "inline" using SoundManager and popping up Youtube players for Youtube links, through $(document).ready(function()).
However, if the user clicks on them while the page is loading, they still get the non-enhanced version.
I've thought about hiding the relevant stuff (via display: none, or something like that) and showing it when loaded, or putting a modal "loading" dialog, but both sound like hacks.
Any better ideas? I feel I'm missing something completely obvious here.
Regards,
Alex
I haven't tested this, but you could try live. The thinking is that you could put your click handlers outside of document.ready so they get executed right away. Since live uses event delegation to achieve it's functionality, you don't really need to wait for the DOM to be ready, and any clicks that are made while the page is loading should still be captured by the event handler.
If that doesn't work, you could try putting the Javascript script tags directly underneath whatever they need to bind. It's not pretty, but it will pretty much eliminate the problem.
Assuming you have used good judgement and people are falling for the non-enhanced version just because the delay is too long then I would use CSS to disable the controls. The CSS will load almost right away. Then using Javascript I would toggle the CSS so the controls are re-enabled.
However, my first reaction is that if the user can click it while the page is loading, then your page or connection is too slow. However, if this is seldom the case--less than 1% of the time--then you can shrug it off as long as the user can achieve his goal, that is listen to his music. I say this because once the users realizes that a better experience awaits half a second later, he will usually wait for Javascript to render and then click.
I take the opposite stance from aleemb regarding using CSS. If you use css to disable the controls, then anyone who has javascript disabled or is using accessibility software will be unable to use those controls without disabling your stylesheet entirely.
You could use a very small inline javascript right before the closing body tag to hide the elements via js really quickly. If it's inline and doesn't have to load external resources it will be very fast, generally faster than a user can click.
However, I do agree with aleemb that if your users are able to mentally process the page and make it to the control they want to click before your js is loaded, there's probably a deeper problem with the way your page is loading. Look into ways to decrease load time: compressing image files, gzipping html/css/js files, minify your javascript, combine images into sprites, etc.
I'd suggest following Paolo Bergantino's advise - event delegation is the way to go to avoid the problem altogether.
I had a similar issue where event delegation couldn't do the job - you can read about that here.