Making figure shortcode responsive

It’d be great if the built-in figure shortcode supported the srcset and sizes attributes to allow for use in responsive design.

It’s a good idea.

But for that to be of any real value (to me, anyway) – it would also do scaling of the image in src. That could be done, of course, but needs some specs, and may be seen in the bigger picture.

I would argue that image scaling would be a nice feature of hugo, but isn’t necessarily a pre-requisite for this feature. I’m using a build system to automatically scale images. Without a responsive shortcode I don’t have an easy way to use the different image sources in my content.

I see Hugo scaling images as an additional issue/feature.

OK, so how would you like it to look like? How smart should/can it be?

<img src="image.jpg"
     srcset="image-1000.jpg 1000w,
             image-700.jpg 700w,
             image-400.jpg 400w"
 />
{{<figure src="image.jpg" srcsetStart="1000" srcsetCount="3" srcSetDecr="300" ... >}}

Me thinking out loud.

Please let me know if I’m completely off base here; maybe this would fit as an additional shortcode rather than extending the current figure implementation.

Would it be easier to pass a directory to the figure shortcode? Say for example I have several different resolutions images of a city in a single directory with their file name being equal to their width in px:

img/city/1000.jpg
img/city/700.jpg
img/city/400.jpg

Would hugo be able to read the filenames and use those as the the source and width descriptors? If so, hugo could set src to the smallest resolution image by default, and the other options would be unnecessary. Is this too much convention?

I think we’d also need the shortcode to accept a sizes input. I think sizes was made required (it used to be optional with a default value of 100vw).

Background on srcset with descriptors and sizes.

I’m not sure a generic srcset is useful, might be a little too limited to serve as anything other than an example. But fwiw I came up with this last year:

<article class="thumbnail">
  <img
  sizes="100vw"
  srcset="/images/mobile/{{ .Get "imgName" }} 320w,
          /images/small/{{ .Get "imgName" }} 640w,
          /images/medium/{{ .Get "imgName" }} 1140w,
          /images/large/{{ .Get "imgName" }} 1280w,
          /images/high/{{ .Get "imgName" }} 2280w"
  src="/images/medium/{{ .Get "imgName" }}"
  >
</article>

Called from content pages like:

{{% thumbnail imgName="myimage.jpg" %}}

Having my build tool output different sized images to different folders allowed for changes in image size configuration without worrying about altering the shortcode or content references to shortcodes and images.

I’m trying to do something similar, but had not yet found a solution for resizing images - on windows. Any suggestion for command line tool?

<figure>
	<img 
		sizes="100vw"
		srcset= "/img{{ .Get "src" }}-small.jpg 600w,
			/img{{ .Get "src" }}-medium.jpg 1200w,
			/img{{ .Get "src" }}-large.jpg 1800w,"
		src="/img{{ .Get "src" }}-small.jpg"
		{{ if or (.Get "alt") (.Get "caption") }}alt="{{ with .Get "alt"}}{{.}}{{else}}{{ .Get "caption" }}{{ end }}"{{ end }}  
		{{ with .Get "portrait" }} class="portrait" {{ end }}
	 />
	{{ if .Get "caption" }}
	<figcaption>
		{{ .Get "caption" }}
	</figcaption>
	{{ end }}
</figure>

{{< foto src="/path/file" alt="DESC" caption="Caption." [portrait="1"] >}}

I would suggest using a node module with bindings to a graphics toolkit. Both of the following include instructions for installing dependencies (low level graphics packages).

I’m using gulp-responsive as part of my gulp based workflow (WIP but https://github.com/adrinux/web-starter-hugo ), gulp-responsive is based on sharp. gm is indeed also useful as rhewitt says, and I have that in web-starter-hugo too, though every site may not need it.

If you’re happy with a non node based cli approach then straight GraphicsMagick/ImageMagick are also good command line tools. Run them via a shell script to keep things DRY.

Edited to add: @phi ‘On windows’, missed that before, sorry. YMMV

@adrinux: thanks for pointing me to the right direction!