Resize doesn't load new breakpoints

[jhatfield]

Hey Túbal,

This may not be a bug but seems like an oversight or maybe just an opportunity. You have loading of images happening on resize if the deferred load is there but resize is not implemented to reload the breakpoint sizes for images based on a new viewport size.

For browsers at least this can be important. If you start at a narrow window size then maximize the browser, image quality can become very poor if images are set to fill the window or even a large container.

Any thoughts? Interested in a pull request if this was added as a config option?

[tubalmartin]

When I was writing Riloadr, I thought about that case.

IMO, there could be 2 "issues":

1) Mixed image sizes:

Loading different image sizes when the browser is resized or when a device orientation changes (different viewport width) could result in a website displaying images of different sizes within the same group of images (all images in a group should be the same size).

This applies if each image is loaded just once (image size is evaluated just once).

2) Multiple requests per image:

To solve the previous issue, different image sizes would have to be requested for an image whenever the viewport width change.

In other words, Riloadr would have to make multiple requests for the same image but in a larger size.

This may be doable if your website contains very few images (small performance & bandwidth penalty) but I would avoid this at all costs since users would have to wait for the larger image to load if a smaller one was already loaded.

Other thoughts:

On mobile phones and tablets, viewports cannot be resized so the calculated image size will fit nicely. However, mobile devices can be rotated to effectively resize the viewport (from portrait to landscape and vice versa) so we'll face here too the issues mentioned above.

On desktops however, viewports can be resized but it's highly unlikely that a user has a tiny viewport when browsing websites (edge case).

Furthermore, images on websites designed for desktop browsers are usually not displayed to fill the total width of the viewport as opposed to what seems a common practice in mobile browsers.

Conclusion:

Due to these issues, I decided to calculate and load the appropriate image size just once.

Did I convince you? I'm open to discussion :)

[jhatfield]

The scenario for resizing a window larger is one of user choice. They have said "I want to see more". The options are: 1) show them nothing more, 2) show them more content (fluid or responsive layout) but with the same image detail or 3) show them more content (fluid or responsive layout) and more image detail.

In some cases where the image is the primary content I think option 3 is valid. In this case loading a larger image is not a burden to the user but is a benefit.

This could be bounded by having an upper limit based on screen resolution, so that someone on a 1280 screen would not be able to load a larger image that would naturally fit on their display.

A typical use case is someone on a 27 inch display who browses with a half screen window. On my website I see about 10k of this type of user each month (about 0.5% of users but influential users, creative people, affluent people). They rarely browse at full screen but in user testing will often resize the screen if they come to a website that looks like it might be better in a wide format.

Additionally there is now a fullscreen spec and support in Webkit and Firefox for fullscreen mode that a user can enable. If this capability is exposed to the user they will click it and then the browser will fill the screen more than when windowed.

I'm not sure I understand your first point about mixed image sizes. These seems like something the developer would control, eg: by defining image sizes for each breakpoint for each group. This of course requires more forethought and planning especially if you want to have one group like in a side column stay at a consistent size but another say in the body resize responsively.

[tubalmartin]

I understand and share your concern @jhatfield

If I were to implement that feature (I may do it) I'd add an optional configuration option such as this one:

var group = new Riloadr({
    // Defaults to false. 
    // If the viewport width changes, Riloadr will check if a larger image should be delivered. 
    monitorViewportWidth: true 
});

Feel free to make a pull request so I can see your approach ;)

[jhatfield]

Will do, thanks

[wilsonwc]

Just put in a pull request for this issue.

[tubalmartin]

@jhatfield I'll wait for your pull request because I'd like to see and test your approach :)

[wilsonwc]

I was also thinking that it wouldn't be too difficult to put another option, say useScreenSize, in order to load the largest image for the screen size, not just the current viewport size. So say someone had a 1440px wide monitor, but their browser width was only 600px when the page loaded the option would force the loading of a larger breakpoint based on the 1440px. Of course this would defeat some of the purpose of this plugin in the first place, but would still serve the purpose of serving different images to different screen sizes.

[tubalmartin]

@wilsonwc Riloadr tries to mimic CSS as much as possible so any breakpoint calculation based on screen size will be discarded.

Thanks anyway for your suggestion :)

[sehmaschine]

just tired riloadr for the first time and I´m quite impressed. but I´m also having the issue mentioned here ... problem is, when I show a responsive/adaptive websites to customers, I´m going to change the screen size (instead of using tablets, handhelds or what have you). in that case, image-resizing would be awesome (though I understand that this issue has no priority).

[tubalmartin]

@sehmaschine I'll definitively look into it ;)

[thomaswelton]

Any update on this. The fact that larger res images are not loaded when I resize my browser up is currently the only reason I haven't settled on riloadr as my responsive images solution.

[tubalmartin]

Version 1.4.0 is out and includes this feature and much more, check it out and spread the word ;)

Thanks for your feedback!