[feature request] responsive images

[crepererum]

Zola already supports image processing, but this is only available either if the template requests it or if a shortcode is used. Images pulled in by markdown (via ![foo](image.jpeg)) are not processed. For large images and for mobile consumers, this is not desirable. I would like to see Responsive Image Tags instead of normal image tags. Ideally, the size (e.g. 1x, 1.5x and 2x) as maximum with/height (similar to the fit image processing operation) should be configurable in the config.toml, since some sites might have different requirements than others (e.g. a coding site vs. a photo blog). An example would be:

image_sizes = {
    1: 100,
    1.5: 200,
    2: 500,
}

Prior art are Ghost and Wordpress.

[Keats]

This can be done as a shortcode no?

[crepererum]

Sure, it can and I think for now this works perfectly. But my argument is that images should be optimized / responsive by default without using the shortcode for every image when writing markdown. Otherwise, authors would end up with using the shortcode all the time instead of the standard markdown way of embedding images, which (IMHO!) misses the purpose of a nice static site generator that has batteries included. Or in other words I'm asking for "build a nice, responsive, optimized site by default".

[crepererum]

An alternative implementation would be to allow themes / sites to create shortcodes that are automatically applyed to every markdown-inserted image. That would be a very powerful tool too, since it would also allow other features (like lazy loading images) on the long run. Question is if you think that would fit the architecture of Zola.

BTW: I'm also willing to try to implement any of these solutions, but it would be nice to get the OK beforehand.

[Keats]

If it's applied automatically, how can you skip that for some images? Also, srcset is not supported on IE so that cannot be the default. This would also deviates from the markdown spec so I really think those should be done via shortcodes rather than the actual markdown,

[crepererum]

If we also set src (which for example could default to the full-scale image) then we automatically also support older browsers (like IE) and I think we would not diverge too heavily from the markdown spec. It is more an addition. But I can see why Zola would like to stick w/ that. An argument for sticking to the standard would be that Hugo requires the same user-hint (also a shortcode).

For which images would you skip that (just to get an idea which use cases you have in mind)? I think the theme and or site-config could decide on that on the opt-in/opt-out of that optimization, so if correctly configured (e.g. not making the 1x images too small), I think for markdown-written content which is in the center of the page (not like a large banner at the top), this would be sane to do.

[Keats]

For which images would you skip that (just to get an idea which use cases you have in mind)

I think for some screenshots or small images for example.

I think the theme and or site-config could decide on that on the opt-in/opt-out of that optimization, so if correctly configured (e.g. not making the 1x images too small),

It would need to be done on a per-image basis no? If you add it site wide only you can be sure someone is going to ask for granularity approximatively 5 minutes after the new version is released

[crepererum]

It would need to be done on a per-image basis no? If you add it site wide only you can be sure someone is going to ask for granularity approximatively 5 minutes after the new version is released

If we would use an automatic shortcode (one that is applied to all markdown img tags), could this one solve the control problem by implementing arbitrary logic? That said, I think you've convinced me that the feature and all the flags should probably not be a Zola feature, but I still think it would be nice if the theme could implement this.

I could open a new issue (and close this) to propose an auto shortcode feature (shortcodes that are applied to certain elements that markdown produces).

[Keats]

If we would use an automatic shortcode (one that is applied to all markdown img tags)

I don't think an automatic shortcode is doable. Shortcodes have a syntax different syntax from markdown and can take arbitrary arguments. I think a theme could provide an image shortcode for example that content writers will need to use explicitily.

[crepererum]

I think a theme could provide an image shortcode for example that content writers will need to use explicitily.

OK. Let's agree on that for now.

Even though I finally got a negative responsive to my idea, thank you very much for the effort and the time and the insights. IMHO, these are treat of awesome maintainers. Thank you :)

[kellpossible]

how about on a per document basis? I'd like to use this to resize down from high quality assets automatically in many of my documents.

[kellpossible]

How about a shortcode that users can elect to use as replacements for default Markdown rendering of certain elements based on their TOML metadata in the file they are editing? And perhaps a global default in main config file which can be overridden? They could supply an image shortcode which includes two input variables: src and alt or something like that? I guess one could also assign shortcodes for some other markdown constructs such as hyperlinks, tables, etc.

Not having control over how these elements are rendered in Markdown has always felt like the biggest constraint to static site renderers like this for me. I've noticed quite a few systems try to work around it by implementing their own extensions to the Markdown spec, which ends up causing fragmentation, and the editor support isn't as good. Just being able to write plain (and relatively portable) markdown would be fantastic.