Hello, I’m intending to create a image-heavy website and about to enter into the world of RWD.
I’m typically from a PHP/MySQL background from years ago, but interested in getting my hands dirty if there are better alternatives out there. Should I be using a specific framework, or should I use a specific language with a noSQL database perhaps?
The main issue is around images, I wouldn’t want to store one big image and the JS or CSS resize it to a postage stamped size image while it still holds the same weight as the original. Additionally, I want to avoid multiple images being loaded (e.g. bigger image overwriting the small default) - but that might be unavoidable.
Is there any solution to this?
I have read whenever uploading an image, it might be best to upload multiple images specifically for each device, and then use CSS to select that image depending on the browser width. There is also adaptive-images.com, which is another option. These all have been about for the past couple of years, so wondered if there is anything that the Sitepoint community recommends.
Simply scaling images via max-width: 100% should be well supported pretty much anywhere. (The one line RWD framework )
Using @media queries is well supported in all but ancient browsers (IE8). Though I would only use that for swapping background images. The previous method will make actual <img>s ‘fluid’ rather than ‘adaptive’ which is way slicker.
<picture> and srcset are fairly new additions, so don’t have IE support. This is a handy resource for seeing what is supported where.
So if I am following you correctly @SamA74 - if having multiple different versions of the image, I would need to use the <picture> attribute? Which probably isn’t a wise idea since IE hasn’t adopted it yet, and if that is the case, then we can kick that one to the long grass since many users still use IE.
Although not discounting the solution by adaptive-images.com, as this uses multiple images without using the <picture> attribute. Is this something worth looking into, or are there drawbacks to this as well?
If it were using the one image, I would guess something like what @ralphm suggests with “max-width: 100%” might be the most ideal?
Think I’m confusing myself. Why isn’t this easier and more straight forward
Very useful website, which will no doubt come in handy in the future - thanks for sharing!
It is as complex as you want to make it.
The very simplest thing is just to use max-width: 100% so an image will never be any bigger than its containing element. Since block elements are fluid by default (width: auto) you now have fluid images. I generally wrap images in a <figure> element which may be floated to one side for smaller pictures, full width for bigger ones. That’s a simple as it gets.
The down side to this is that if you have a 1600px wide image, that same image gets downloaded to a 320px wide mobile.
Ralph’s method gets around this by using heavy compression, so although the image is hi-res the file size is small. The concern then is that heavily compressed images can look a bit rough. But it is demonstrated that when displayed at a reduced size they actually look OK.
As an alternative, you may use the srcset attribute to swap out the images for smaller versions on smaller screens.
Regarding support for this, I have not rigorously tested it, but I “assume” that since you still have the good old src attribute in there for the default image, the srcset just gets ignored by unsupporting browsers. So nothing is broken, they just get the default image size.
I believe this is correct. It’s not for different resolution versions of the exact same image, but different substitute versions to better fit the layout.
For example you have a big wide horizontal banner image, it looks great on a big monitor. but on mobile it’s too shrunk so you can hardly see what it is. Picture could swap it for a narrower or portrait orientation version, or whatever fits that layout better.
If you require any further confusion, here is some more reading on the subject:-
I haven’t started the project yet so I’m open to ideas, but will probably look towards PHP if there isn’t a strong reason against it. Thanks anyway @SamA74, I can look into this in the future sure, just thought it might have been something that’s easily known!