fenton Posted August 19, 2011 Share Posted August 19, 2011 maybe it's something with his setup on that site, try it with this demo: http://mattwilcox.net/archive/entry/id/1053/ Link to comment Share on other sites More sharing options...
ryan Posted August 19, 2011 Share Posted August 19, 2011 I'm pretty much getting the same result there. Clear cache and cookies, open tiny browser to the other demo URL. First load is a big 1-megabyte image. Hit reload and it's is a smaller 78k image. First and second load screenshots attached. Are you getting a different result? I was confused by your screenshot, because one of them did show the 205k image as being loaded, so wasn't sure what you meant? Link to comment Share on other sites More sharing options...
fenton Posted August 20, 2011 Share Posted August 20, 2011 hey Ryan, check this out: http://responsiveimages.splyte.de/ it's a barebones setup. i found out, that if the cookie is set by referencing the js file, the resolution isn't stored correctly. if i set the cookiy by including the script directly, everything works as expected. cheers, jan Link to comment Share on other sites More sharing options...
Matt Wilcox Posted August 20, 2011 Share Posted August 20, 2011 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 Link to comment Share on other sites More sharing options...
Matt Wilcox Posted August 20, 2011 Share Posted August 20, 2011 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. Link to comment Share on other sites More sharing options...
Matt Wilcox Posted August 20, 2011 Share Posted August 20, 2011 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. Link to comment Share on other sites More sharing options...
Adam Kiss Posted August 20, 2011 Share Posted August 20, 2011 Hi all! Interesting debate you've got going off around here! Unfortunately, I am not able to test all this stuff (too much on my plate already), but I have one note though: Is this still responsive design? As I understand it, responsive design is about modifiying design & visuals of the very same content, which is not this case; in the load time you load the same stuff indeed, but the 'differentiate data' part is moved to client with jquery and ajax, so after all, you do not serve the same content (understood? good ). That's all I wanted to say, good luck with bug hunting Link to comment Share on other sites More sharing options...
apeisa Posted August 20, 2011 Share Posted August 20, 2011 Matt, nice that you came in to tell more. I stumble to your blog from time to time, and will subscribe now, since I think you have pretty good solution here. I will test more when I get my internet access back, but it sounds like a great solution when you are taking existing site and turning it to a responsive. Ps. While you are here, please take pw for a test drive, would love to hear your thoughts Link to comment Share on other sites More sharing options...
fenton Posted August 21, 2011 Share Posted August 21, 2011 but it sounds like a great solution when you are taking existing site and turning it to a responsivei'd say, it's the best approach for delivering appropriately sized content images at the moment overall Link to comment Share on other sites More sharing options...
ryan Posted August 21, 2011 Share Posted August 21, 2011 @MattWilcox–thanks for your posts here. It sounds like the solution you've put together is intended to only send the target image size, rather than the result I was getting (both large & target). When exhibiting the intended behavior, it seems like this would be ideal especially for the situation we were talking about (images in a richtext field). My other concern about a similar approach (from another site) was the security of creating any number of resized images... filling up the drive. But yours only outputs predefined sizes, so that is great. @kunane–given that I recommended this as a possible solution [with reservations] even when I thought we had to live with both images coming through, now I would definitely recommend this solution [without reservations] for the question you had. Here's a few impressions about the different solutions. I don't think I would use both solutions together. If you are using Matt's solution already, I don't think it would be worthwhile to use the <noscript> solution with it because all the JPG requests are already going to be routed through Matt's PHP script (unless you exclude certain dirs). My impression is the <noscript> solution may be one to consider in cases where you have markup control (like in PW templates), already have full image size control (again, like in PW templates), want no server overhead (routing image requests through script), don't want to install anything, and/or want to be able to fine tune the various sizes used in a per-image basis. The <noscript> solution may lose some of it's convenience outside of a system like PW, because you may have to manage the various image sizes manually. Matt's script takes that role if your site is compatible with globally predefined sizes, which could be really convenient. That's my impression based on what I know so far, but I've not used any of these techniques on a production site yet. What are the other situations where you would use one solution over another? Link to comment Share on other sites More sharing options...
Matt Wilcox Posted August 21, 2011 Share Posted August 21, 2011 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. Link to comment Share on other sites More sharing options...
ryan Posted August 21, 2011 Share Posted August 21, 2011 Thanks Matt, this is awesome. Thanks for making this new version so quickly. Btw, my comment about the cache was a compliment for your solution. I was comparing to the context of another solution I saw that provided no limits on the number of cached/resized images... thousands of size variations per image could either turn into a DDOS attack or fill up a drive before long. I completely agree about drive space being cheap–might as well use it. ProcessWire works the same way your script does in that it only allows the target image dimensions to be specified by the developer. Link to comment Share on other sites More sharing options...
diogo Posted May 6, 2012 Share Posted May 6, 2012 Apeisa, I was testing your method for responsive images http://www.monoliitti.com/images/, and somehow, with screen.width it's not working in any browser. It always shows the larger image. When I replace screen.width by $(window).width(), it works perfectly... Link to comment Share on other sites More sharing options...
apeisa Posted May 6, 2012 Share Posted May 6, 2012 Diogo: actually not my method, just a implementation of the idea that Ryan got here in this topic. screen.width looks for actual screen resolution, not just window width. So it does work, you just cannot test it easily on desktop. Link to comment Share on other sites More sharing options...
diogo Posted May 6, 2012 Share Posted May 6, 2012 makes sense, sorry... Link to comment Share on other sites More sharing options...
JeffS Posted May 30, 2012 Share Posted May 30, 2012 Hi All, I am wondering if it would it be possible to use the new language features in 2.2 to create different versions of content for mobile devices and tablets. Detect on the front end and redirect to the right "language". That way you could have content optimized for device groups. I know Adobe has taken this approach with there BC platform. I have not looked in to the language features yet as I am new to PW and just getting my feet wet. @Ryan - Fantastic project. Excellent documentation. Impressive forum participation. Wow. I usually build highly structured sites and PW fits that like a glove plus it looks like a winner for marketing sites / landing pages. Impressed and thankful. Cheers. 3 Link to comment Share on other sites More sharing options...
diogo Posted May 30, 2012 Share Posted May 30, 2012 Welcome to forum Jeff! You certainly could do this, and I don't see any inconvenient besides loosing the possibility of using the language feature itself. I think I would prefer to create special mobile fields for each field that needs a different content instead, but I understand that your plan can be more practical. Maybe it would make sense to create a new module, based on the language module, to create this functionality without interfering with languages. Link to comment Share on other sites More sharing options...
Soma Posted May 30, 2012 Share Posted May 30, 2012 Hey Jeff, welcome to the forums. It "would" certainly be possible to use language fields, but I would not recommend. Better to use alternative fields for mobile, or even separat tree. A a simple example have a "body" field for normal desktop, and a "body_mobile" field. So you'd add a check for mobile and have a $mobile var with the string "_mobile". And add that to the fields you need. echo $page->get("body$mobile"); Not sure if that's the best way to go, but certainly a simple one. Link to comment Share on other sites More sharing options...
JeffS Posted May 30, 2012 Share Posted May 30, 2012 Thanks for the welcomes. @diago - I will look into this as an option. I want something that would make sense for content editors and would be easy to deploy, but Soma's approach would be logical if I was in a rush. Just exploring the idea and getting familiar with the API. Link to comment Share on other sites More sharing options...
ryan Posted May 31, 2012 Share Posted May 31, 2012 If you don't need to use LanguageSupport for actual regional languages, I think it would be fine to use it. It's been kept intentionally a bit abstract in that 'languages' can mean anything that localizes text. While we think of that as being to a person and their language, there's certainly no reason why you couldn't also look at that as localization to a device. I think you might also find the code internationalization convenient. However, it's good to consider what Soma said too as there are certainly some simple routes you can take that don't involve using LanguageSupport. And the concern with LanguageSupport is that you might use that to serve alternate versions of content at the same URL, which might not be beneficial to your search accessibility (Google, etc.). So if you do use LanguageSupport, you'd just want to activate the language based on hostname or something (i.e. m.domain.com vs. www.domain.com). Link to comment Share on other sites More sharing options...
JeffS Posted May 31, 2012 Share Posted May 31, 2012 @ryan - Thank you for the information. As I progress with this I will provide feedback on my outcome. Link to comment Share on other sites More sharing options...
jacmaes Posted June 8, 2012 Share Posted June 8, 2012 I started building responsive sites more than a year ago, and like everyone else I quickly realized that the weakness of that new method / philosophy is serving the same image to all devices, from mobile to desktop. Matt Wilcox's Adaptive Images (server-side resizing) works great, but like JeffS above, I'm interested in optimizing content for device groups, i.e. content optimized for mobiles, tablets, desktop and even smart TVs. I've come to the conclusion that to do this efficiently, device detection has to be done on the server. There's even a buzzword for this new technique: RESS, or Responsive Design + Server Side Components as coined by Luke Wroblewski. WURLF is the most famous device detection database, and there are some good tutorials to get you started such as NetMagazine's, but it seems to me way too complicated for simple projects, and WURLF has turned into a commercial project anyway. I've been looking at two recent projects that seem very promising: Detector Categorizr Categorizr is by far the simpler approach, and I like how it turns the traditional and much-decried User-Agent sniffing on its head: it assumes that whatever is not detected as desktop and TV (which are relatively easy and safe to detect) is a mobile device. In other words, it's a mobile-first based device detection. Clever. Here's a test page I created using Categorizr and that you can check on your mobile, tablet, or computer that will show different content according to the device used (disclaimer: not fully tested): http://www.arqyestud.../categorizr.php Combining this server-side detection technique with the versatility and power of PW could make for very powerful and easily-maintainable 'hybrid' responsive sites. What do you guys think? 3 Link to comment Share on other sites More sharing options...
SiNNuT Posted June 8, 2012 Share Posted June 8, 2012 I haven't used it myself but i hear good things about Foresight.js Link to comment Share on other sites More sharing options...
JeffS Posted June 12, 2012 Share Posted June 12, 2012 I will be testing a cloudflare pro feature that serves up images based on the device type from the proxy/cdn versus trying to address it on the backend for now. Might save me some dev time for a low budget site. Here is a good resource - Responsive Images Community Group @W3 in case your interested. [EDIT] - Corrected broken link. Link to comment Share on other sites More sharing options...
diogo Posted June 13, 2012 Share Posted June 13, 2012 another one for the toolbox http://jquerypicture.com/ Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now