You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If this lands, it will be a 2.0 release & thus will be the distinguishing feature between v1 and v2.
Most of the time when I'm trying to do a fair bit of animating, it's never on a <img/> directly. It's nearly always on a <div> with a background-image style property.
In those cases, I'd (presumably) like to know when the image has completely downloaded before I begin the non-critical animation. IMO, it's far worse to have something fly/scale in, only to be partially loaded and/or lag the browser while it tries to pain the image and animate at the same time.
Here's how it would look, I think:
// load all <div>s' background-imagesonloaded('.slide > div',{background:true});// load the background-images on .container's .slide nodesonloaded('.container',{background:'.slide'});
I'm only guessing, but doing so may add roughly ~100-200 bytes, which is a significant increase since 1.0 is only 350 bytes.
Please cast your vote below 😆
The text was updated successfully, but these errors were encountered:
Most of the time when I'm trying to do a fair bit of animating, it's never on a
<img/>
directly. It's nearly always on a<div>
with abackground-image
style property.In those cases, I'd (presumably) like to know when the image has completely downloaded before I begin the non-critical animation. IMO, it's far worse to have something fly/scale in, only to be partially loaded and/or lag the browser while it tries to pain the image and animate at the same time.
Here's how it would look, I think:
I'm only guessing, but doing so may add roughly ~100-200 bytes, which is a significant increase since
1.0
is only 350 bytes.Please cast your vote below 😆
The text was updated successfully, but these errors were encountered: