i just love that srcsets are now createable by kirbys core but it gives me a bit if of a headache how to proceed with my srcset plugin. it provides a filemethod by the same name but with different result. i need to change it to avoid confusion.
any suggestions?
What does your srcset plugin does different then the built in in 3.1? Maybe focus on that more?
my plugin creates an img or picture element with srcset, sources attributes and optional lazy loading class. it also provides a kirbytag to do the same. plus minor features.
the new 3.1.0-rc1 srcset filemethod “just” creates the srcset string. which makes total sense imho.
srcset to imgWithSrcset and pictureWithSrcset.but i can not just change it easily (major version required to avoid auto update) since my plugin got quiet some download count. 400+ in packagist and about the same as zip on github.
I can imagine the built in tag being expanded over time to include much of this. I used your plugin, but once the core srcset gets a Kirby tag, I will probably switch to the built in srcset instead.
I think the only real difference at that point would be that yours generates a choice of picture tag or image tag?
you still have to create the img element everywhere then. personaly i use it a lot since $img->html() was dropped in k3. but might be personal preference i also use the Html class a lot instead of writing html tags.
the plugin can also populate picture element sources which i use to add webp etc in addition to jpg for some clients.
Why dont you call them picset and imgset - i hate long tag names 
@bnomei, if I get it correctly, your plugin now facilitates a function to build <img>-elements, with optional lazyloading-classes?
And, it foresees in a kirbytag for responsive images. AFAIK this is not (yet?) in core.
Personally I see value in the kirbytag, but the first item is too abstract for me to use.
@bnomei as much as I hate having to write the srcset attributes by hand, I was never able to use your plugin because of the lazy-loading feature. For most of our projects we use a frontend framework that already has a lazy-loading library built-in - UIKit - so that would be a double-whammy…
@luxlogica please take a closer look. the plugin does not include lazyloading js libs. it can add a customizable lazy class string but thats all.
i should add sizes support to make it less optimized for the lazysizes lib.
Probably a personal matter too, but I tend to like managing stuff like lazysizes in my JS build (and not via a Kirby plugin). For finding the targeted elements in the HTML, its usually only a matter of adding a class or data-attribute on them (and you don’t need a plugin for that imho).
the plugin started to help be build picture elements with sources for jpg and webp plus secset magic. i have an automated buildchain to create the web from jpg (my cloudconvert plugin). it was really helpful for me to reduce that to one simple filemethod.
since picture and img are kind of related i decided to support both in the end.
@bvdputte creating the html tag for img is simple indeed. picture with sources is a bit more of a hassle so i decided to automize it concerning DRY.
but getting back on track. the problem with the overlapping filemethods persists. i do not want my plugin to override usefull core functionality. lets say i want to keep the html tag creating part of the plugin and do a major version increase to avoid confusion. what would you do? how would you rename them (picset/imgset etc…)
As far as I know, you can’t override native methods in a custom page/file etc. method (only in a model). So your method will stop working.
I’d call them pictureElement() and imageElement() instead of srcset() or picset() because your plugin is adding stuff to the HTML element. And longer names are sometimes easier to understand and to remember and less likely to clash with other generic abbreviations.
On a side note: because working with responsive images is fairly complicated and best practice remains a moving target. I’ve also written my own snippets and kirbytags to convert images and use webp and different lazyloading techniques in the past.
I had considered your plugin a few times already to ease this pain, but despite its configurability, it never fully met my special requirements. But I am aware that it wasn’t meant as an universal solution and there are many cases, where it is just right and saving time. Therefore thanks and appreciation.