Jump to content

Matt Wilcox

Members
 View Profile  See their activity

  • Posts

    4

  • Joined

  • Last visited

    Never

 Content Type 

Everything posted by Matt Wilcox

  1. Matt Wilcox
    Hi everyone I've just released a new version (1.2) with the following improvements: NEW FEATURES * Support for PNG and GIF images * Added ability to sharpen re-scaled images (see CONFIG, $sharpen) BUG FIXES * Better extension detection (.jpeg was failing) * First-run Firefox bug fixed. The JS must be in-line, in the <head>! DETAILS: Firefox (and potentially others, but not observed anywhere else) was requesting the first <img> before it loaded the external javascript file, even when in the <head>. This caused Firefox to load the full-resolution image the very first time the site was visited. All subsequent page views were fine. OTHER IMPROVEMENTS * Cleaned up the .htaccess file and included clear comments on use * Vastly improved instructions and examples on the downloadable zip * Since 1.1 fixed issues with browser cache, default cache time now set to 7 days * Refactored PHP code That should fix the problem where FireFox was loading the very high resolution image on the first visit to the website. Please let me know if you have any issues with the new 1.2 version http://responsive-images.com @Ryan - No problem, it's been great to see that people are using RI and are giving such good feedback. Fingers crossed that bug has now been fixed! Yeah, the cache this system builds could get pretty big and is definitely something that needs consideration from anyone wanting to use it. My feeling is that disk space is pretty cheap these days though, and the resultant saving on bandwidth from the hosting perspective as well as the end-user will probably be a good offset.
  2. Matt Wilcox
    Hi again everyone, From a rapid bit of testing on my local network I can confirm that the problem is the JavaScript being in an external file. If you wish to fix this, just take the contents of the .js file and put it inside script tags in the head, instead of referencing an external JS file. I shall release a fix for download tomorrow - I'd do it today but I'm not going to have time.
  3. Matt Wilcox
    Oh, also important to note: The behaviour of the process has changed since the demo - resizing your window will no longer have any effect on the size of the downloaded image! It used to use the browser width instead of the device width to decide which image to download; I had to change this. The problem with that first approach is when browser caching is taken into account (my demo didn't allow the browser to cache the image, but you can't do that on a real site). The issue was that if you loaded the site in a small window you got served the smallest image that would work - but then your browser cached that image. Which meant as soon as you maximised your window, the images were no longer big enough - you had to clear your cache to get the right image. Obviously this was no use, which is why it now detects the maximum size your screen can run at and uses that instead.
  4. Matt Wilcox
    Hi everyone, Thanks for your interest in this project! I can see there's some debate about whether the system loads the large image first or not. The short answer is "no" but the long answer is "very rarely" and I'm tracking down the reason so it can be fixed. Here's how the process works: The browser loads the site, starting with the HTML. It reaches the JavaScript which is in the <head> and immediately executes that JS. The JS asks the browser what the maximum screen size of the device is, and stores that number in a cookie. The rest of the HTML then loads. As soon as the browser hit's an <img> tag it attempts to load the image from the server. But, because of the .htaccess rule the server - instead of simply sending the JPG - it first loads the PHP. The PHP then has a look to see if there's a cookie with the screen size - if there is it simply sends an appropriately sized JPG back (or generates a new JPG if needed). As you've seen though, that isn't always what is happening and so far I have two potential reasons: The first is that I recently made the JS an external file instead of in-line in the head. Which means the browser may be loading that at the same time as the HTML, and may in fact reach the HTML images before the JS has had chance to run - which will mean that on the first request there is no cookie. I think this is the most likely explanation, and if so I'll simply revert back to the JS being in the head instead of a file. To be honest I was going to revert it back to this on the next release anyway. The JS itself is now far simpler than in the 1.0 release - it's back to being a 1-line call, so it doesn't make sense to be in its own file anyway. The second potential reason is to do with a recent bug report on Firefox: There appears to be a minor bug in how FF works, and on the very first load of the page (and only that load), the browser does not send the cookie data along with the image. Which means that the PHP script falls back to serving the original image that's linked to from the HTML. Which, for my example site, is a ridiculously large 850kb image. A bug report has been filed with Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=680462 I'm currently investigating which is the cause, and will hopefully be able to roll out a v1.1.1 bug-fix release in the coming day or two. I am also looking at getting the project put onto GitHub so this kind of feedback is handled faster and more effectively. Thanks everyone for your interest and time -Matt
×
×
  • Create New...