Continuing my learning curve with Source, I’ve hit a problem I can’t resolve.
In preview the image for the Hero banner is shown resized to fit the screen for iPhone SE, but when published live it is shown severely cropped horizontally on my iPhone SE. I have used a small and medium+ image in the Container Plus stack as required.
I had the same problem with the section banner images further down the page but resolved this by using an Image Fit stack within Container Plus, which resized the images appropriately on the iPhone. So it seems to be related to the way the Container Plus stack is processing its images. I can’t use the same workaround on the Hero container as I need to overlay the call to action buttons.
I accept that I’m probably doing something wrong!
The problem occurs on all pages but is most evident on the About page.
Your image is a challenging one for small devices portrait devices because because that dandy fellow pretending to catch a fish, is on the far right of the image.
I assume you are using the image as a background image in a Container. You have 2 options really before trying a different image.
There are alignment controls in the Container Plus stack to align the image center, center, right,center, etc., and you may be able to align the image so that it looks better on a portrait iPhone. I.e. try right,center for small.
You could also use the small medium and large image feature, but use a different image for the small one that is either completely different or trimmed to show what you want to appear on an iPhone.
The proces can involve a lot of trial and error with challenging images.
It’s in a Source Container Plus, which allows two images, Small and Medium Plus, which I have used.
What I can’t understand is why it renders perfectly in Preview, and why if I use a Source Image Fit stack (as I have done in the section headings as a workaround) the images render properly on the iPhone.
Container Plus uses background images and therefore it is the content that is added to the container that sets the height of the container (and with that how much of the image is seen as the image is cropped to suit that height). You can override the height of the container by using the min-height values and this will let you control how much of the image is seen a bit more. As Gary says too - you can also control what bit of the cropped image is seen by using the different alignment/anchor settings for the background image.
Where you want to see the full image - like you are currently using for your section header images then you would just add a regular image stack. You have used Image Fit but the regular Image stack would have worked the same way. (Image Fit gives you the additional option of controlling the height of the image)
In short - whether you use background images or regular images will depend on the role of the photo. If they are just to give a nice background to other content (text and buttons etc) then use container Plus. If the image is the focus then use an Image stack.
OK, it seems that the Container Plus treats the images differently to Image or Image Fit. I’ve tried experimenting with the height settings but it only squashed or expanded vertically the view on the iPhone while still cropping horizontally.
I still find it strange that RW Preview shows it rendering correctly.
Your example shows an iphone in landscape. Look at that image and you will see that the bottom of the same image displayed on the larger image, has been cut off at the bottom.
You can’t display a landscape image in a portrait sized display witout losing some of the image or reducing the height of the image so that it’s width fits the portrait device, but will then be much smaller.
When you add a normal image (not a background image) to a page, the height of the image you see, will be automatically determined by the width of whatever is containing it.
In your case you are adding text and buttons inside the container that is using an image for the background.
If you add an image as a background into a container and preview you will not see anything. Then add some comtent such as your buttons, you will see an amount of the image set by the height of the content, i.e. your buttons.
Therefore, you need to work out how to control the height of the container for small to large and portrait or landscape. You could do this by setting the height to something like 90vh. Then see if it works.
Thank you for that explanation @Webdeersign. That makes complete sense. It’s pretty obvious that the preview is in landscape but I completely overlooked that fact! At the same time I had sort of come to the conclusion that the button group was determining what I was seeing without fully understanding the underlying reason. As I said at the outset, I’m on a learning curve.
Now that I understand what’s going on I have a better chance of sorting things out.
That’s the key word here. You have to either make compromises in your choice of image or in what gets cut off.
I used to “really sweat the details” as they say , and try to make everything work in landscape and portrait on mobile. However, I think today, that mobile users are smart enough to switch from landscape to portrait if a site does’nt look right.
Here’s a suggestion I’ve made before for ‘hero images’ which can make a big difference to their size and load time. If you create a Source Grid for the hero image (in this case 100vw wide and 100vh high, to fill every size of device window), and you’re reasonably handy with PhotoShop or similar, you can use this trick.
Make as low a resolution version of the whole image as you can get away with — aim for something about 60-80kb. Don‘t worry about the loss of detail in the area where the camera was focused. Put this in whatever image stack you want to use inside the first Grid item.
Then create a new Grid item underneath this in Edit mode. Give it the same position in the Grid as the first item, so it will be directly over the top of it (as a layer). That is, if your grid has only one column and row, both items should be made to fill row 1, column 1. Then, in Photoshop, on a duplicate of the original photo select the part of the image which is in sharp focus (you and the rod) and delete the rest, so that the rest of the image is transparent. Then save/export/squash this so that the detail is still sharp. With a bit of fiddling around, you might be able to get your image down to about 130kb, something like that. Put this image, in the same kind of image stack as the first, in the second Grid item.
What you’ll have is a sandwich of two layers — a lower resolution background layer of the whole image and a higher resolution foreground layer of just the detail. The Grid will keep the two images locked together at the same width and height at every size and ratio. It will look like a high resolution image (because even high-res images generally have a limited depth of field), but it will be about 200kb, rather than 1.3mb.
As a bonus, you can then put the text you want over the top of the image in a third identical Grid item stack — this is effectively turning Rapidweaver into layers. And if you specify the text and other items’ sizes in vw (viewport width units — 1/100 of the width of the screen), they will be perfectly responsive, scaling up or down to fill the same percentage of the screen at each viewport.
Simple CSS Grid (Source Grid Plus Pro): 1 column, 1 row, all three grid items designated as occupying column 1, row 1 (total overlap).
Background image: ‘extreme’ lossy webp (just to make the point): 33kb
Foreground image (woman’s face) full resolution png*: 232kb
Type layer: text positioned with vw horizontally and with % and transform vertically, sized with vw but clamped at lower limit.
Original image: 938kb at this resolution
I’ve used png for the foreground image because webp compression, although it supports transparency, seems to put an unsightly border around the image. If I can find a way around this, lossless webp will give much smaller file sizes.