dazzyweb Posted August 30, 2014 Share Posted August 30, 2014 Hi I want to Fully support retina devices for an image gallery but not sure of the best way to do this in processwire. I want this to be as simple as possible for the admin with 2 images produced after one is uploaded. One for normal and one for retina screens. Then pull the correct image depending if the screen is a retina screen or not. I am interested how others here support retina screens in processwire especially with an image gallery. Link to comment Share on other sites More sharing options...
adrian Posted August 30, 2014 Share Posted August 30, 2014 Not specifically about retina images, but rather responsive images in general and the polyfill for the new standard: http://css-tricks.com/video-screencasts/133-figuring-responsive-images/ Includes mention of providing a specific 2x version of images. 3 Link to comment Share on other sites More sharing options...
horst Posted August 30, 2014 Share Posted August 30, 2014 https://processwire.com/talk/topic/6472-charleswuorinencom/#entry63522 https://processwire.com/talk/topic/6538-using-procache-with-wilcox-adaptive-images-plugin/page-2#entry64304 3 Link to comment Share on other sites More sharing options...
adrian Posted August 30, 2014 Share Posted August 30, 2014 Remember though that srcset is not available that widely available just yet: http://caniuse.com/#search=srcset So that link I sent you to mentions the picturefill polyfill that you'll need to get going with it now: http://scottjehl.github.io/picturefill/#getting-started 2 Link to comment Share on other sites More sharing options...
dazzyweb Posted September 2, 2014 Author Share Posted September 2, 2014 Thanks adrian and horst. I will checkout those links. Link to comment Share on other sites More sharing options...
Martijn Geerts Posted September 2, 2014 Share Posted September 2, 2014 You've to watch out with the picturefill polyfill. Picturefill works mobile first for every image loaded. This means, that for every needed image, the mobile version is also downloaded. (except when you're on mobile of cause) Link to comment Share on other sites More sharing options...
MadeMyDay Posted September 2, 2014 Share Posted September 2, 2014 This means, that for every needed image, the mobile version is also downloaded. Sure? The polyfill is loaded first and alters the src according to the matched media query before any image is actually downloaded. You can easily prove that when looking at the network tab in chrome dev tools. 1 Link to comment Share on other sites More sharing options...
Martijn Geerts Posted September 2, 2014 Share Posted September 2, 2014 (edited) Maybe I installed it wrong, or something. But the network tab shows my story. I do think this is default behaviour of most/all browsers. As soon as it sees the src inside an image it starts downloading. Almost sure that this is before the stylesheets/scripts are loaded. (ps, I did use the img srcset version) edit: it looks like that chrome handles it as one resource, but Safari loads the low and high res. So it could be possible that the srcset is now handled by the browser, thus bypassing picturefill. Edited September 2, 2014 by Martijn Geerts Link to comment Share on other sites More sharing options...
MadeMyDay Posted September 2, 2014 Share Posted September 2, 2014 As soon as it sees the src inside an image it starts downloading. Yes. But the src should be altered by the polyfill before loading it. That's the reason why the JS should be placed in the <head>. (ps, I did use the img srcset version) Haven't used the v2 of the polyfill yet since v1 works pretty well. As long as the element's distribution in current browsers isn't given, I'll stick with it. Okay, honestly: I stick with it because I have written a jQuery plugin that relies on the <img>-version Link to comment Share on other sites More sharing options...
Martijn Geerts Posted September 2, 2014 Share Posted September 2, 2014 Yes. But the src should be altered by the polyfill before loading it.The DOM can't be altered when the DOM is not ready, thus what you say must fail if the browser hasn't support of the scrset them selfs. Just reading smashingmagazine, they say: The most glaring difference between this snippet and the specification is the absence of a fallback src attribute, which was intentionally removed to prevent images from being downloaded twice in unsupported browsers. And, really, what would be the point of this if images were downloaded twice? Other than that, it’s pretty faithful to the specification, but it will probably evolve over time as the specification fleshes out and the polyfill matures. So here we found the issue I do use the src atrribute, because I like the image to be an image without javascript 2 Link to comment Share on other sites More sharing options...
-aj- Posted September 3, 2014 Share Posted September 3, 2014 So here we found the issue I do use the src atrribute, because I like the image to be an image without javascript Put your fallback image within a <noscript> tag, solves this issue (won't be inserted into the DOM /evaluated for SRC etc) unless JS is turned off, and keeps the fallback. Can bloat the code a little, but much less so than downloading 2 images. Also you could setup a build system like grunt or gulp to add the noscript fallback automatically during the build process. 5 Link to comment Share on other sites More sharing options...
Martijn Geerts Posted September 3, 2014 Share Posted September 3, 2014 (edited) You could always hack a solution, I proposed the same over here. But as the srcset becomes the new standard it's good to throw a warning for double loaded images here on the forum. Only browsers that support the srcset will not double download. Altering & changing the standard to your own needs is just an ugly hack and not much better that all the other solutions to the problem. Edit: MadeMyDay posted about the v1 picturefill version. The way that works isn't that bad if you realise that the standard is not yet widely spread. Edited September 3, 2014 by Martijn Geerts added comment about MadeMyDay's way Link to comment Share on other sites More sharing options...
bwakad Posted September 4, 2014 Share Posted September 4, 2014 The trouble with browsers, screens and phones are a pain in the ^&*. 1. Browsers control HOW they want to display elements. 2. CSS and HTML5 wants to display their standard for elements. 3. Jquery wants to give you in between solutions. 4. Phones adjust their sizes and each brings their own standards. 5. And every month we go back to 1 again.... I have given up on anything that is not crossbrowser, or cross phone, sort-a-speak ... If we only had 1 browser, 1 screen size, 1 phone and 1 camera, life was so much simpler. Link to comment Share on other sites More sharing options...
LostKobrakai Posted September 4, 2014 Share Posted September 4, 2014 If we only had 1 browser, 1 screen size, 1 phone and 1 camera, life was so much simpler. One working and from all browservendors agreed standard would be sufficient. 2 Link to comment Share on other sites More sharing options...
Recommended Posts