Image scales, srcset, picture, source, oh my!

I'm on a quest to get <img> tags on steroids :sweat_smile: and if possible, done by Plone on its own :grinning_face_with_smiling_eyes:

Anyone has pointers on how to get that working? I summarized our requirements on this issue in github, but hopefully here gets a bit more attention :grinning_face_with_smiling_eyes:

There is a lot to get here, but it might be that some of you faced the same problem? That example <picture> element on the issue is coming from our frontend developer/designer working with static assets, but generating that automatically is quite a bit more work :sweat_smile:

Anyway, any pointer or idea would be great :grinning_face_with_smiling_eyes:

Image handling and srcsets were discussed quite extensively for Plone 6 (Volto):

We are still in the process of implementing this. PLIP #3279 is a precondition for sane scales that can be used by srcsets:

If I am not mistaken @nzambello put quite some effort into this recently.

If you are starting with image optimizations I would highly recommend the book "Image Optimization" by Addy Osmani:

If you plan to work on this for Classic I would highly recommend syncing with the Volto efforts. Otherwise, we would end up with two different implementations of srcsets in Plone.

Thanks for the pointers :+1:t4: I will have a look, but although we are growing a internal only volto frontend, we mostly need the srcset for the server side rendered version of the website so far. I hope we can get this to work from the backend as well.

Hi Gil, I'm working currently on an implementation for Plone 6 Classic-UI.
My plan is to get a configuration into the tinymce or image handling controlpanel, where an admin can define sourceset mappings. Somthing like this:

image_sourceset_mapping = [
    {
        "id": "full-content-width",
        "title": "Full Content Width",
        "preview": "++theme++barceloneta/static/fullcontentpreview.png",
        "mapping": {
            "sm-l": "large",
            "sm-p": "larger",
            "lg-l": "great",
            "xl": "huge",        
        }
    },
    {
        "id": "half-content-width",
        "title": "Half Content Width",
        "mapping": {
            "sm": "large",
            "lg": "large",
            "xl": "large",        
        }
    }
]

This will be used by TinyMCE to select a image variant and the fallback scale will be inserted. The markup inserted by TinyMCE will look as it is now, except some additional marker CSS classes.

The actual convertion of the img/figure tag to a sourceset, will be done by a transform when the page is rendered first and cached.

This way is safe to update images and also the sourceset definitions later on with out having to update all content items.

I would be happy to have a chat about this with you. You can find me on Discord. On Wed we will sprint there in the classic-ui channel anyway and i want to work on that task.

2 Likes

@MrTango that's a nice coincidence then :grinning_face_with_smiling_eyes: I will try to remember/add a note on my calendar about Wednesday, as I, indeed have this need right now as well, and if I can be useful even better :sparkles:

Is there any in-person/online sprint planned for classic any time within the year? I might have, finally, some time for that starting on June/July and I'm all looking forward to that :rocket:

1 Like

There is the Buschenschank Sprint 14.-19. May near Graz (Austria), which @thet organizes.

for your specific problem, if you are generating XML with a <picture> tag, I think you are creating a new output mime-type. it's no longer text/html.

plone.outputfilters and it's resolve_uid_and_caption could get a new transform from x-html-safe to text/my-new-mimetype that does this magic for you.

See Plone Outputfilters and TransformChain (how to display things differently) I should upload those slides somewhere I guess.

I do something similar to make google amp replies use <amp-img> tag instead of <img> we have a collection of image templates we use, and simply register them with zcml. We switch between them using layers or output mimetypes.

<browser:page
        name="plone.outputfilters_captioned_image"
        for="*"
        class=".captioned_image.CaptionedImageView"
        template="captioned_image.pt"
        permission="zope.Public"
        layer="rfasite.basetheme.interfaces.IRFASpecific"
    />

Note how our image tags change when you request

https://www.rfa.org/english/news/myanmar/burnings-03092022193907.html

verses

https://www.rfa.org/english/news/myanmar/burnings-03092022193907.html/ampRFA

I think your problem is very similar, but much more verbose.

Caution: Opinions.

I really hate that most of the really cool html-image transforms are happening on the field level using plone.outputfilters and not so much has been built into portal_transforms.

But I do understand that the output mime-type of a field could be different than the output mime-type of a HTTP reply. I just wish I could use the power of output filters on the entire response instead of just a single field.

The solution may also be too tightly coupled to TinyMCE - but I'm not sure. I don't use other wisiwig editors and haven't run into the problem.

I really think that some of the problems could be solved better using the .tag() method found on OFS.Image . I've always hated that deep-down, the tag() method returned HTML that was hard-coded into python. I want to be able to customize the output of '.tag()' as flexible as how output-filters does it.

Deep, deep down, I think that 'image.tag()' is bad anyway, as it is too tightly coupled between the object and it's representation, but I've been told it's convenient syntax.... which is a horrible excuse.

So anyway, yeah.

2 Likes

Hey, I just read the plone 5 docs today! So I'm glad someone wrote this.

https://docs.plone.org/develop/plone/images/templates.html#tag-method

But I'm also going to say that '.tag()' could be resurrected if it could find a template through a layer and maybe a response content-type - and build it like outputfilters resolve_uid_and_caption works.

I'm not saying it's a good idea, but just an idea.

Question: In the control panel, there is a setting for 2X, 3X images. How should these settings be taken into account when creating image_tags 'manually' ?

1 Like

I don't think the statemant is correct, maybe it was for the Archetypes version.
The tag method is very alive and will not go away. In the new Plone 6 i documented it a bit how you can use the tag/scale methods for different scenarios. Sometimes you need more control, then tag() is not the right choice, but often it is.

Plone Foundation Code of Conduct