Using ProCache With Wilcox' Adaptive Images Plugin

[bytesource]

I am positively surprised about how much I have learned about different solutions to adaptive images so far in this thread. 

Though I am not an expert, I would like to add my personal observations:

Bandwidth detection: I get this feeling that this is mostly useful for dedicated mobile websites, as these solutions seem to always be serving an image of the same size, albeit at different resolutions. But I would not want to serve a large image to a mobile device, even if bandwidth was not an issue. Instead, I would prefer a smaller version of the original image but at the same resolution.

Image URL: The Adaptive Images plugin I mentioned in my first post scans all <img> tags in order to later set the image url of the src attribute according to the user's screen width. However, I am often more concerned with the presentation of large images in image galleries, and these images tend to be loaded via JavaScript targeting the href attribute of a surrounding <a> tag:

<a href="path/to/large-image.jpg">
    <img src="path/to/thumbnail.jpg"/>
</a>

Because of this, any solution to adaptive images should be able to let me determine the path to the actual image.

Cheers,

Stefan 

[Martijn Geerts]

The Adaptive Images plug-in you've linked to is probably the best solution for small website with not many visitors and no Pro Cache. I do like the concept of your adaptive image solution the mosts. But on the same time I don't think it's possible. Say the visitor who firstly visits the page has a 27" iMac, he creates the static cache file for Pro Cache. The next visitor has an iPhone on a sloppy connection. You can't serve them the cached  version. So you need to serve your page in runtime and create a new cache. And I do think you don't want to create for every width a new image. 

Bandwidth detection is very tricky. The solutions by SiNNut are clever, but don't cover every aspect. There's clever detection for 3g and other cellular settings that would bypass the test for the performance. Great but doesn't work if I hook my iMac to my phone as internet deliverer, then the actual test kicks in. (Logical and it does what it must do) Testing network speed shouldn't be done every image, you're losing speed over there so they take a snapshot, one test to decide which route to take. This snapshot could be to positive or to negative. A to positive result we definitely don't want.  I'm not really convinced with the bandwidth at the moment. Please tell me if I'm wrong here.

[MadeMyDay]

Interesting discussion, happy to chime in here.

I am a bit ambivalent here. For one, I would welcome any PW-related approach as a new InputField or alike. But in my experience all of the approaches - client or server side - were trying to fill a gap which had no standardized solution yet. But since W3C filed the specification for srcset attributes and picture elements my way is to go with exact that (even not implemented) syntax. Chrome implemented those lately (in Canary, behind dev flag), others will follow. 

I used the picture polyfill a lot in version 1, where it was more of a likely implementation of the proposed picture syntax. In version 2 we can use it right away with the correct syntax and from my observation it works great. So I would suggest not to build a custom (hacky) solution and reinvent the wheel but use that polyfill for not supported browsers (all at the moment, but less in the future). 

What I usually do is use the CropImage plugin for handling those different sizes. That works great. For example a slide show I am building the markup for each image looks like this (picturefill v1, so no picture syntax here yet, but works the same):

                 <span class ='image' data-picture data-alt='{$slide->title}'>
                        <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpagesmartphone')}'></span>
                        <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpagetablet')}' data-media='{$tablet}'></span>
                        <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpage')}' data-media='{$desktop}'></span>
                        <!--[if (lt IE 9) & (!IEMobile)]>
                            <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpage')}'></span>
                        <![endif]-->
                        <noscript><img src='{$slide->sliderimage->eq(0)->getThumb('fullpagesmartphone')}' alt='{$slide->title}'></noscript>
                    </span>

So it supports JS-disabled browsers as well as older IEs. You have total control over the images which those browsers get served. BTW: My media queries get imported by a global JSON file, I use that in CSS as well as in JS, but that ist another topic. Just consider for example $desktop be something like "screen and (min-width:1024px)".

Advantages: I have full control and only have to configure CropImage for serving the different image sizes. Even art direction is possible (for example 2:1 on desktop, 1:1 on mobile). In that example I have no 2x configuration but that is also possible with srcset in picturefill v2 or with a media query like "screen and (min-width:1024px) and (-webkit-min-device-pixel-ratio: 2)".

What I think regarding PW and responsive images: Try to keep the markup out of the solution or just provide a standard markup which everyone can change. Like PW always does. I would also rather extend the great CropImage module than trying to build something new. For example put a configuration in CropImage for 2X images. Could be done easily I think like:

smartphone,200,200,template,2x

so both, the 200x200 and a 400x400 version is generated from the same crop. The advantage of CropImage definitely is the art direction possibility. I wouldn't like to lose that ;-) 

[Martijn Geerts]

@MadMyDay, tnx for you well thought insights. I think you hit the nail on top with your post. Love the CropImage approach.

or just provide a standard markup which everyone can change.

Love to see a template-able adaptiveRender() methode or something.

[horst]

Love the CropImage approach too, - especially the art direction possibility!

But want to mention that there maybe also an interest of getting adaptive / retina images for people who don't want use the cropimage module.

Do we need to create two modules?

Or can we say if you need adaptive images, just load the thumbnail module and specify three target variations but with only one dimension to get an uncropped but resized version:

smartphone,200,0,template,2x

Does this result in a 200px width and a height according to the aspect ratio? (there was lately an update with cropimages module, but haven't downloaded and installed it now.)

But can this really work? Or are these two usages to different?

I want my adaptive images created on upload! if I don't want use art direction via cropimage module.

-------

Like Martijn, I also want to have an adaptiveRender() method.

Could this be an optional feature, that a developer doesn't have to use, but is able to use? To use it he once should have to provide a template markup with placeholders for the image variations.

-------

The basic root seems more clear after @MadeMyDays post. Only I haven't got which way to go with simple adaptive images on upload (imagesfield) and the more individual way with crop images. Also a usage of both should be possible in one site / on one page.

Any thoughts / hints / tips on this?

Edited June 3, 2014 by horst

[bytesource]

I like the idea of going with the future standard as proposed by @MadeMyDay. The only problem I see is that this approach probably does not work in situations where the large image is linked to a href attribute, as is the case with most galleries a la Lightbox.

I also like the idea of taking advantage of the CropImage plugin. However, it would be great if CropImage could free me from the tiredsome work of cropping different sized versions for each image. For example, being able to define the focal point (the center of the crop) in the Admin would be real timesaver in this case. Here is some more information on the focal point.

Cheers,

Stefan

[Martijn Geerts]

I could be me but I don't see differences in lightbox behaviour with the adaptive Image vs the old way. It's just the same old <a href=''> wrapped around the picture. I do think Lightboxes will be more clever in the near future to address linking to different popup sizes. (maybe there are some adaptive light box plugin out there right now).

Lightboxing to different sizes or disabled at all for the various viewport sizes needs additional javascript logic. But these problems are not that difficult to solve.

[MadeMyDay]

maybe there are some adaptive light box plugin out there right now

yep. http://dimsemenov.com/plugins/magnific-popup/

Lightboxing to different sizes or disabled at all for the various viewport sizes needs additional javascript logic. But these problems are not that difficult to solve.

nope. Just use something like enquire.js and define your lightbox logic only for bigger screens. No need to get rid of the linked image, that is just fine: http://bradfrostweb.com/blog/post/conditional-lightbox/

[MadeMyDay]

The only problem I see is that this approach probably does not work in situations where the large image is linked to a href attribute, as is the case with most galleries a la Lightbox.

No problem. Most modern lightboxes allow ajax driven requests. So just define a picture template and link that. Add the page id, image field name and count to it like

<a href='/mypicture/?id=12&imagefield=images&count=2'><picture...></a>

Or just keep inking to the (big) image. Even on smartphones this could be a desired way of showing details of a product. No need for a smaller version here (most of the time).

[bytesource]

@MadeMyDay

Or just keep inking to the (big) image. Even on smartphones this could be a desired way of showing details of a product. No need for a smaller version here (most of the time).

Why do you think there probably is no need for a smaller version of the image viewed fullscreen on mobile devices? For me this use case is my main concern as I have relatively large images with a width of 1400px that I don't want to show on smaller screens.

Cheers,

Stefan

[MadeMyDay]

Why do you think there probably is no need for a smaller version of the image viewed fullscreen on mobile devices? For me this use case is my main concern as I have relatively large images with a width of 1400px that I don't want to show on smaller screens.

We are talking about linked images. Not images that are shown on page load. If I click on a link which targets an image (for example in a shop) I perhaps WANT to have a detailed version of the image I clicked/touched on and want to pinch and zoom to see the details.