Skip to content

set sizes for picture-tags, fixes #179 #180

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

MrTango
Copy link
Contributor

@MrTango MrTango commented Apr 22, 2025

also: allow to set lazy to false, to suppress the loading="lazy" attribute
this needs to be merged together:
plone/plone.outputfilters#86
plone/plone.base#80

@mister-roboto
Copy link

@MrTango thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

@MrTango MrTango force-pushed the mrtango-image-sizes branch 2 times, most recently from affa538 to 4e707b9 Compare April 22, 2025 15:38
@MrTango
Copy link
Contributor Author

MrTango commented Apr 22, 2025

@jenkins-plone-org please run jobs

scale_url = self.update_src_scale(src=src, scale=scale)
source_srcset.append(f"{scale_url} {scale_width}w")
source_tag = soup.new_tag("source", srcset=",\n".join(source_srcset))
if not sizes:
sizes = f"(min-width: 576px) {target_width}px, 98vw"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 576?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scale_url = self.update_src_scale(src=src, scale=scale)
source_srcset.append(f"{scale_url} {scale_width}w")
source_tag = soup.new_tag("source", srcset=",\n".join(source_srcset))
if not sizes:
sizes = f"(min-width: 576px) {target_width}px, 98vw"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@erral erral left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only thing I see here is that if I request to create the picture tag without requesting any picture_variant but I request an explicit sizes, the generated img tag lacks the srcset and returns the original image in its src.

I understand not requesting any picture_variant and passing an explicit sizes as a way to render the full picture tag with the source with its srcset but passing a custom sizes instead of relying on predefined picture variants, which gives the template developer full control over the rendered HTML code.

This is what I wanted to achieve also in #170 but rendering a single img instead of a full picture.

@erral
Copy link
Member

erral commented May 9, 2025

Moreover, I have a question:

If after these changes we are just rendering one source tag, why do we calculate different srcset for each source depending on the picture_variant? We can use the picture_variant to render a different sizes and leave the srcset always the same (rendered with all scales).

This way the code is much simpler and also is the configuration of picture variants.

@MrTango
Copy link
Contributor Author

MrTango commented May 13, 2025

The idea is, that the picture variants are defines, as they needed by a designer/integrator or Developer. Calling the picture method without a picture variant does not make sense in my world.
I wanted to avoid that developers have a different way of doing it. Because that leads to templates or code which has to be overridden to customize, when we could just define it all in the control panel or via XML.

Maybe let's have a short call these days on discord.

@MrTango
Copy link
Contributor Author

MrTango commented May 13, 2025

I'll give a talk about the picture variants at the German Plone-Tagung and will probably also hold again in English, maybe at PloneConf if i can make it.

@erral
Copy link
Member

erral commented May 14, 2025

The idea is, that the picture variants are defines, as they needed by a designer/integrator or Developer. Calling the picture method without a picture variant does not make sense in my world. I wanted to avoid that developers have a different way of doing it. Because that leads to templates or code which has to be overridden to customize, when we could just define it all in the control panel or via XML.

Maybe let's have a short call these days on discord.

I see your point, but that requires developers to predefine the picture variants in the controlpanel, while, as I see, just calling the method and passing the required sizes attribute, would make rendering the HTML tag pretty automatic: always all scales in the srcset and custom sizes.

Anyway, we can talk durinng the Beethoven sprint also :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants