I'm building a slider. There is a set of slides, which I'm using as a content source and this content is appended to a transition wrapper everytime the slide is changing. After the transition finishes, the transition wrapper is removed from DOM. When I add completely new content (image) to the slider and I open it in Chrome for the first time, this image is not, of course, in Chrome's cache. The problem shows when I append the transition wrapper (with this new image) into DOM. Chrome sometimes (and sometimes not) sends a request to get that image and recieves a 304 response. It makes this request even 3x for the same image. But it really happens only when the slider with the new images is loaded for the first time. After refresh, the Chrome gets those "new" images from its cache and the slider works perfectly. Other browsers are OK.
BTW: I also use imagesLoaded plugin, but image preloading doesn't seem to have any effect on this problem.
I know there are better approaches to create image slider - using images as background-image etc. But my content source => transition wrapper is the way I'm using to create responsive / not-only-image / CSS3 slider.
I'm going to release this plugin soon, so I would really like to solve this problem quickly.
Related
I try to get my head around the relatively new img attribute "loading".
I understand that if an img has the attribute loading="lazy" then it will tell the browsers that support the attribute, that it can be loaded when getting near the viewport.
So why not always set loading="lazy"? Those images that appear instantly on the screen would get rendered anyways, as they already are inside the viewport. So basically loading="lazy" is ignored in that case anyways.
I also see in this demo https://mathiasbynens.be/demo/img-loading-lazy that the pictures in the top of the dom are having the loading="lazy" attribute set.
I got the link above from: https://web.dev/native-lazy-loading/
Thanks in advance :)
You should avoid setting loading=lazy for any images that are in the first visible viewport.
Source: https://web.dev/browser-level-image-lazy-loading/#avoid-lazy-loading-images-that-are-in-the-first-visible-viewport
In short, if the image is not loaded lazily, the browser can start fetching the resource immediately. Lazy images need to wait until the Layout phase of the browser rendering pipeline, to determine if an image is in the viewport or not.
Adding loading=lazy unnecessarily will likely add a small amount of delay until your webpage is fully rendered.
One of the reasons I can think of to not always use lazy loading is when the network can be disrupted. In that case, you want to download as much as possible while the connection is active, so that the most of the page is usable when the connection is down.
It’s a hint to the browser that the image might not be immediately useful/visible and that it should prioritize other resources. The third image in an image carousel or images appearing far down on the page are some good examples of when this attribute is useful.
Overly lazy implementations, such as Firefox, don’t images until they’re scrolled into view. This causes the browser to display a white area while the image is being loaded. This isn’t an ideal user-experience. Chrome, on the other hand, loads images 3000–8000px before they appear on screen which is too eager again.
Chrome won’t load lazy-loaded images even when they’re within the viewport for background-opened tabs. This is caused by a limitation of Chromium’s IntersectionObserver and may be fixed in a future version.
I am creating an AJAX transition between to pages where I have a hero image which stays the same on both pages.
After clicking on a link, I center the image, add the new HTML behind and fadeOut the center Image.
The problem is, even with a cached image (it is the same file) I see the image appearing suddenly in the behind (from AJAX response, rendering after appending to DOM) when fading out the image in the front.
Even by adding a little delay to the fadeout of the image in front, the image in the back is still no ready. (Probably the rendering just takes more time).
My options would be to wait for the Ajax image div to have rendered completely (which I don't know how to do), or – and that is what I'd like to try:
Replace (copy) the image within the AJAX response before adding it to the DOM.
Is this even possible, and will it help improving the performance?
I will also try to replace the div immediately after replacing the content with the AJAX response.
Any hints are still very welcome.
cheers
You could set the css z-index property so that the top image stays on the top. And set an event listener so when the image underneath is finished loading you can fade out the top image.
$('#bottom-img').on('load', function() {
$('#top-img').fadeOut();
});
Well thanks for the answer. This is what I meant. This would require some waiting for the image to finish loading and then fadeOut the top image. But I got a nicer solution:
Because the two images are exactly the same, I replace the content in the back (ajax response), and immediately after I copy the image on top into the ajax response (so I replace the image with an already loaded one).
Then I fade Out immediately.
This gives me a very smooth looking transition and the downside of the «waiting until loaded» is gone.
(In comparison to my initial question, where I wanted to replace the image within the ajax response before adding it to the DOM, I now add it to the DOM and manipulate it immediately.)
Thanks anyway.
Cheers
I have a weird problem. I have a script that loads images into the SVG, and then user can manually update they order by clicking on them: the clicked image goes up in the SVG tree.
The problem is that in Chrome all images blink when their order in the tree is changing. However, Firefox and Safari work with no blinking. Moreover, I have a copy of this script on the other domain and it doesn't blink there too.
Is it possible that the blinking is caused by some domain-related issue? In both cases images are on the same domain as the page. I use Chrome 18.
You can call suspendRedraw() method on any element in SVG when you need to make complex manipulations or when you encounter bugs like you are describing. And when you're done with manipulations call unsuspendRedraw() on the same element to let browser rerender the image. I would call the methods on the parent element of your images.
I'm new to webkit animations and I have been trying out to do this kind of animation
http://demo.jeffrey-way.com/tutsMobile/#site.php?siteName=psdtuts
If you click the list element you will see page sliding in and sliding out.
I want to implement this animation to my app which is built with backbone.js, underscore.js, zepto.js
I could use jqTouch or jquery mobile but I would like to make it as light weight as possible, because I'm building it only for IOS. So thats way I wan't to implement it by my self.
Any hints to make this implementation or should I go with jqTouch?
In this example, there is some sort of (I hate to be vague...) ajax based content loading system. Take a look at the source:
<div data-role="page" id="article.php?siteName=psdtuts&origLink=http%3A%2F%2Fpsd.tutsplus.com%2F%3Fp%3D15026" class="ui-page ui-body-c">
When you first visit, that div doesn't exist. It's created by javascript when content is required, then filled with that content, then translated (animated) into the viewport.
Here is a step by step, deduced from a quick look at the page:
Base page is loaded, including css, javascript, nav list
Script is waiting for a nav item to be clicked.
Upon clicking, an ajax request is made to the content corresponding to the clicked item; determined by href="article.php?siteName=psdtuts&origLink=http://psd.tutsplus.com/?p=15081". My guess? This ajax request is getting content from the same place as psdtuts.com, likely in a database.
While that stuff is loading, javascript shows a loading animation. When loading is complete, it's hidden again.
Once the new content-filled div is created, it is given a default position with its left edge placed right outside of the right edge of the screen. Upon the event of being positioned, javascript then determines the view's dimensions and translates the div across the horizontal dimension. At the same time, the nav list is moved the same direction and distance.
When back is clicked, the view's dimensions are determined again (In case the window size changed) and the nav and content are translated to the right, hiding the content and showing the navigation again.
Repeat
I could be off from how this exact sample is being done, but... Well, this would work.
You wouldn't be that crazy to use a framework for something like this, but I can understand wanting to do a custom job. It would certainly be faster for users, but slower for you. Depending on your intent, that would be just fine.
edit: If you're only serving this to users with webkit, using a framework is even less necessary... If you're not worrying about cross browser support, there's really not a lot going on here that you couldn't accomplish easily with raw javascript.
The only reason I use jQuery for example, most of the time, is to ensure things work alright in most use cases. It just smooths so many things out... Even if 95% of the framework isn't being utilized, it's worth it when you've got a deadline.
I founded out one good example
http://andrew.hedges.name/blog/2009/05/29/animating-your-iphone-web-application
It's not possible to set transparent background for WebBrowser of WP7. To make impression of transparent background I want to do the following workaround. I want:
To find a position and size of WebBrowser on the page.
To get page's background image.
Crop it with values what I found on step 1.
To save result in IsolatedStorage
To parse HTML and place <body background="RESULTBACKGROUND">
MyWebBrowser.NavigateToString(NewHtmlString);
I think this should be a workaround of transparent background and should work.
For now I am trying just to place any .jpg image (let's say test.jpg) on step 5.
But fail. I have "Build Action" property of file set to "Content". It is placed in the root of the project. And <body background="test.jpg"> not working. Back of the WebBrowser is still white.
What I am doing wrong?
UPD:
Step 5 is solved.
2Claus: No! Not only from web. I saved both html file and image file to IsolatedStorage and WebBrowser can show image as a backgroud.
Now the problem is that background cannot be fixed. I tried many differrent things with styles. I also tried to add a fixed div behind my text. Nothing works. The picture is always scrolling with a text. I tried to add onscroll event and pass it scrolled value to move the div in an opposite direction, but div is glued to the page :(
Any ideas?
So assuming you're talking about the WebBrowser control, you're forgetting that the HTML only can refer to urls on the world wide web.
So either you need to host your background images on a website, or you need to inject a CSS style that sets the background to either white or black (the two default background-colours of the platform).
For WebBrowser, You don't actually have to save it to the ISO to make changes on the page. You can load it navigate to it normally, and then use InvokeScript to make the changes via custom JS code. It can be a little tricky though, as you will probably need to heavily rely on the eval and stringization. The problem mentioned by Claus is still there - but you need to do some experiments. With the Mango release and SDK 7.1+, the platform support IsoltatedStorage imagesources in the form of is://path/file - maybe - maybe - maybe squared - the webbrowser's renderer udnerstands them too - then setting your bkg's url to such would work. I doubt though, as it could be seen as some minor security breach, etc
I now bumped into the same background fixed image problem. For someone wandering here I solved it placing content into a fixed-height container (div) therefore the container contents is being scrolled and not the html page, leaving background picture "fixed".
body
{
background-image:url('...');
background-position:-20px -150px;
background-repeat:no-repeat;
background-attachment:fixed;
}
div
{
height:300px;
overflow:scroll;
}
Of course background-position and div height is set specifically for a WebBrowser position in page and it's size.