Hi, how can I make this open slow?
<script>
(function(){function i(){var r=this.id.replace(/\D/g,""),i="box1";n[i]=!n[i],t(r,n[i]),localStorage.showing=JSON.stringify(n)}function t(n,t){document.getElementById("chk1").checked=t,document.getElementById("box1").style.display=t?"block":"none"}var n;n=JSON.parse(localStorage.showing||"null"),n?t(1,n.box1):n={box1:!0},document.getElementById("chk1").onclick=i})();
</script>
What do you mean by open slow? Do you want:
I mean when I click the link for “box1” div it pops open instantly I was wondering if there is a way to have it open slow. Not sure if it will work with this code.
Just slide open slower.
Yes there are ways. It’s complex without libraries to help though. If you are already using jQuery, that can help to make it a painless process.
What animation effect do you want? For it to grow vertically in size? For it to fade in?
I have jquery 2.0 something running on the page but couldn’t find a way to use it in this situation. See this has a storage cookie that remembers the last state the div was in, i.e. open/closed after page refresh. I would like in to slide down/open not fade.
Okay - well I have a code example here that does both. It’ll be easy to modify it to fit your situation.
CSS is used to achieve this:
#box1 {
transform: scaleY(0);
transform-origin: top;
}
.slide-down {
transform: scaleY(1);
transition: transform 0.95s ease;
}
Just add the slide-down class to the element and you should be all set.
Thanks for your help. It’s okay, I just thought it might be something easy, like adding “slow” somewhere. 
That’s what makes libraries such as jQuery so tempting for people to use.
Yeah, one day I’ll get around to it.
In the meantime, welcome to vanilla JavaScript. Vanilla or plain JavaScript is a the name that’s given to JavaScript when you avoid the use of large libraries such as jQuery.
I am interested in your view on the compatibility of the proposed solution. After reading about the CSS transform rule I find that it is listed as experimental, as detailed in the following link.
MDN
I also find that the JSFiddle example shown here throws errors in IE7 and IE8. Would you say that this solution is suitable for production, or should it be flagged “user beware”?
I am often surprised at how many script solutions I see on the internet that are not what I would call “backward compatible”. These cases are usually excused on the grounds that few users have older browsers, but even a few percent of the world’s internet users is still a very large number. How do you think we should handle this difference between what is possible and what is practicable?
IMHO the key concern is what percent of your users.
Although it is nice to think that everyone everywhere in the world using every available browser will visit your site, do the facts reflect that?
And what percentage of your users would you be prepared to accept not being able to use your site? Can you put a number on it? 2%, 5%, 10% - more?
Personally I’d be prepared to lose a percentage in the low single figures - less than 3% maybe. At that point I’d put my time and effort into ensuring my site was both accessible, and RWD compliant. I’d rather pick up additional customers that way, rather than chasing the far end of a fart in older browsers.
Not really a number, but more a priority.
Last I checked, there was a significant trend towards an increase in mobile devices.
It isn’t that I would write off other visitors completely, as time allows, but it doesn’t seem prudent to not focus efforts on the reality.
IMHO the situation is pretty clear… IE7 and 8 are dead, and anyone still browsing the web with them is probably in much greater trouble than a few broken web sites. What you might do is display a friendly reminder that it’s a serious security risk to use them and a few things won’t work as expected, rather than expensively trying to get everything to work there with elaborate fallbacks etc.
I feel that this is something that is best determined by the person receiving the advice. If they are using the code for production work, it is normally expected that the people putting it into production are aware of compatibility issues and that ie8 usage is at 5%
Having said that though, it is important that issues of compatibility and usability are covered too.
That’s a good question with no easy answer
I think first and foremost you need to know your own audience in case your stats differ from the norm but I tend to drop support for old browsers when the browser maker no longer supports that version and stops security updates.
Microsoft stopped supporting Ie10 and below back in January and the usage of old ie is now down to about 3% or less.
The problem I see with supporting an old un-supported browser is a bit like a car mechanic allowing you to drive your car knowing that its not safe. Entering credit card information into old browsers like IE8 is like playing Russian roulette and indeed banks will no longer support old browsers for this reason. If you support these old browsers then you may end up encouraging users not to upgrade while at the same time putting them at risk to viruses and whatever other holes have been found in their browser code.
Of course if the site is simple and has no forms or interaction with the user then I don’t see a problem in making the page viewable in an older browser. In most cases they just don’t get the fancy stuff.
I also find it a little strange that some people advocate supporting IE8 yet have done nothing to support mobile which has now overtaken all desktop internet use. The same applies to accessibility and inaccessible sites will lose you more users than all of IE put together.
In the end its a balanced choice that you need to make for your particular circumstances but I see that within another 12 months old IE browsers will be off the chart altogether. Especially as you can download a better browser quite easily these days.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.