Even Better Responsive Image Support?

Archive
1

@Gertt has done some excellent work in getting the first responsive image support into a CMS that I’m aware of that works through Grav’s impressive image handling features: http://getgrav.org/blog/retina-responsive-images.

By marking up an image in an .md file like this:

![Alt Text](image.jpg)

and providing an image file like:

image@2x.jpg

you get HTML like (simplified for illustration):

<img src="image.jpg" alt="Alt Text"
	srcset="image@1x.jpeg 300w, image@2x.jpeg 600w" sizes="100vw"
	data-src="image@1x.jpeg" data-srcsetfallback="true" style="">

Cool!

When the browser first parses this code, it wants to get started downloading the image file right away, even before it has composed the page layout and determined the actual width of the image on the page. All it knows at that point is the screen density and the viewport width.

So, if it’s running on a retina display with a viewport width of 1000px, it’s going to download the image2x.jpeg file. Even if it later finds out that the image is in a narrow column and ends up being displayed at 100px wide.

Grav defaults to using sizes="100vw" because it has nothing else to go on. Only the author working on that website knows how wide that image might be.

Can we/should we want to extend Grav even more by providing Markdown syntax that Grav understands that could be used by the author to define the sizes= to be used?

We have media actions. Could sizes be another?

2

P.S. Please correct any misunderstandings I may have exposed. :slight_smile:

3

I think that having user configurable size attributes would be a worth addition to our responsive image handling. Definitely something we can discuss for a future release. Especially as retina style displays are getting more and more popular.

4

I totally agree! I would suggest to declare the sizes option as an query parameter like

![Alt Text](image.jpg?sizes=300vw)

then we don’t have to alter the Markdown syntax and the user can decide on their own.

Further it should be easy to implement though. If not please correct me.

5

That should be quite doable, just another addition to our existing markdown link handling method.

6

Should I open an issue on GitHub for this, or are feature requests handled another way?

7

Issue on GitHub would be good for tracking purposes.

8

Done.

9

Will possibly part of next Grav release (see https://github.com/Sommerregen/grav/commit/73491fc8015bf1a404bec3d7cff8397d1a1ef65e)

10

Nice! And thank you.

11

@Sommerregen, going to submit a PR on this? Would love to add it in to Grav. Cheers!

12

Wouldn’t this need 2 parameters for image size and screensize?

I might be misunderstanding but it seems like just specifying an image width you would need to add the image width as the browser width parameter as well. So an image resized to 300px would have a srcset width of 300w also?

But if you have an image that takes up 50% of the screen you would want to resize to 500px for a screen of 1000w (and not a 1000px image or specify a screen width of 500w)

13

@rhukster Done!
@rwent There is no need for 2 paramaters. The widh and sizes option are independent of each other. If you change the width, Grav automatically calculate the needed srcset for your (presumed you have more than one image of the format image@n.jpg, where n is just a number). The sizes option instead tells your browser, which image of your srcset shall the browser load, i.e.

<img srcset="large.jpg 900w, medium.jpg 600w, small.jpg 320w" sizes="(min-width: 50em) 33vw, (min-width: 28em) 50vw, 100vw" src="small.jpg" alt="" />

will load medium.jpg if the viewport is 700px having a width of 50% (if the viewport is 700px wide, than 700px > 28em and the first media condition is triggered. Since the image shall have a width of 50% (350px > 320vw) the browser loads medium.jpg).

14

Ok, so the sizes parameter specifies the browser breakpoints and the images are resized in multiples of the original?
image.jpg = 100px
image@2x.jpg = 200px
image@3x.jpg = 300px etc?

So if I added an image named image@6x.jpg grav would essentially do the rest and in future you would be able to modify the sized through a query?

I should really just have a play with it and see what happens :slight_smile:

15

Hi @rwent, yeah the sizes option can be understood as a parameter to specify breakpoints. It generally tells the browser, which size should be used to select the image from the srcset.

To have responsie images in Grav you must have the image like ìmage.jpg and at least a file named image@1x.jpg. The width and heights can be very different e.g. ìmage.jpg could have a width of 500px, whereas image@1x.jpg could have a width of 700px. It depends on your choice.

What Grav then does is the following. It detects the alternatives (here: ìmage@1x.jpg) of ìmage.jpg and determines their sizes and automagically generates the srcset attribute (here “image.jpg 500w, ìmage@1x.jpg 700w”). Without the sizes attribute ìmage@1x.jpg will be shown only when the viewpoint is greater than 500px. With the sizes attribute you can modify the viewpoint width (which is by default the browser width). 100vw means full browser width. 50vw means half the browser width.

It is best to see an example and figure it out on your own. The sizes option is not available in Grav 0.9. 20, but it will be soon. For the moment you can play around using Gravs built-in support for responsive images and modify the page in your browser via Firebug or something similiar.

16

Perfect, thanks. I think I was getting confused thinking that grav was automatically creating the different copies of the images.
I need to get back into grav and take a look, unfortunately the day job tends to get in the way :frowning:
I think Koken does something very similar to this but totally javascript based and I think it’s all automatic so there’s no control outside the theme

17

Actually Grav does automatically create any missing images. If you have one image called image@3x.jpg it will create @2x and @1x versions automatically.

You can however provide all the versions if you wish, but why bother when Grav can automatically do that for you.

18

That’s cool.
That’s why I was thinking about the params in the first place. How grav knows what size to make the other copies.
Anyway, I just need to spend a bit of time playing with it.
Keep up the good work!