Srcset support for `(image: ...)`

[tobiasfabian]

I think you are planning something like this: (image: plant.jpg srcset: aside) or (image: plant.jpg srcset: 300, 800, 1024])

Which will be super cool!

Maybe it’s difficult to explain content editors the meaning of srcset. What do you think about a srcset field property like this.

fields:
  text:
    label: Text
    type: textarea
    srcset: 300, 800, 1024

So the content editor can just throw in images and all images will be automatically resized with the given srcset.

Another idea would be srcset presets per textarea field. Like this:

fields:
  text:
    label: Text
    type: textarea
    srcsets: 
      default: 300, 800, 1024
      cover: 800, 1024, 2048

But maybe that’s too much.

[bastianallgeier]

@tobiasfabian I love this idea!

[distantnative]

This would mean that we need to load the blueprint when rendering a page. Usually we don’t do that.

Alternatively the blueprint settings could only have the effect that the right srcset attributes get entered when using the textareas toolbar.

[iamwebrocker]

This is cool, I just thought about tinkering with the (image: ) kirbytag in a similar way. To keep simple I thought about using srcset preset names defined in config.php image -> thumbs -> srcset … (which I have there defined anyway) and then using the image->srcset() function in the tag's php section. :)

[moritzebeling]

Theoretically:

• For a website to be responsive, all html image tags shall come with a srcset. That includes all images placed in Textareas and Kirbytags.
• Blueprints are places where the layout of the panel and the content structure of a page is defined. It is not the right place to define how output is rendered, while Kirbytags are already the place to define how single html tags from a text block are rendered. srcset is an attribute of the <img> html tag, so it should also be an (optional) attribute of the corresponding Kirbytag, just like alt, title or class:

  (image: 1.jpg srcset: 400, 800, 1200) // list of pixel sizes
  (image: 1.jpg srcset: medium) // preset name

• ⚠️ But: it also should never be the task of an editor to make the website run properly, that's the job of the designer/developer. It must be possible for an editor to only care about content, and still have all the functionality that the website requires.

---

That means, additionally to the Srcset option in the Kirbytag, there should be a way to define default values of Kirbytags. Where would be a good place to do that?

• Overriding the Kirbytags with custom tags extensions?
• As an argument passed to kirbytags() and kirbytext() like:

  // in template or snippet
  $page->myField()->kirbytext([
  'image' => [
  'srcset' => [400, 800, 1200]
  ]
  ]);

• A new yaml file where default values of tag attributes can be specified?

  // site/tags/image.yaml
  attributes:
  srcset:
  - 400
  - 800
  - 1600

• Or maybe best, since it’s almost there: In the config file, just like the video options:

  // site/config/config.php
  return [
  'kirbytext' => [
  'img' => [
    'title' => 'An image with srcset',
    'srcset' => [ 400, 800, 1600 ]
  ]
  ]
  ];

PS: Sorry, but personally I am very emotional about this, since Wordpress so heavily messed up the separation of editing content and rendering layouts.

[bvdputte]

I fully agree with @moritzebeling : this should be invisible for editors if possible. A set of opinionated defaults, set in the config.php would also be the first place where I'ld look to set this (consistent ith video options).

It would be a plus to expose this in the kirbytag as described above by @tobiasfabian for the more advanced editor.

If you want this to be configurable per template, but don't want to read blueprints on read content, you could also add this to config.php e.g. like this:

// site/config/config.php
return [
  'kirbytext' => [
    'img' => [
      'default' => [
        'srcset' => [ 400, 800, 1600 ]
      ],
      'template-a' => [
        'srcset' => [ 200, 400, 800 ]
      ],
      'template-b' => [
        'srcset' => [ 300, 600, 900 ]
      ]
    ]
  ]
];

[ipenburg]

Who's problem are we trying to solve here? It's not like it's currently impossible or even hard to create a responsive website with Kirby. Based on a visual design you can choose if you need to implement only some automatic resolution switching or need to also bother editors with solving art direction problems. If it's not clear what built-in srcset support is supposed to solve we probably just end up with an opinionated default that ticks some responsive checkbox without much additional value over a less complex solution.

So, maybe it makes sense to formulate this feature as a User Story: As a < type of user >, I want < some goal > so that < some reason >?

[distantnative]

Since this doesn't seem as clear cut and with our ambition to reduce issues in this repo to mainly bug reports, I have created a Idea on Nolt referencing this great discussion: https://kirby.nolt.io/112