search

adobe / aem-core-wcm-components

Standardized components to build websites with AEM.
https://docs.adobe.com/content/help/en/experience-manager-core-components/using/introduction.html
Apache License 2.0
733 stars 741 forks source link

[Container] Adaptive Image Renditions for Background Images #774

Open HitmanInWis opened 4 years ago

HitmanInWis commented 4 years ago

The WCM Core Image component has automatic adaptive images to ensure that appropriately sized images are used given the current viewport and CSS styling. However, this same functionality does not apply for components with background images, such as Container. This means if a user uploads a 10MB image for use of a Container background, the image will render on the web in its full 10MB glory.

Looking on the online guide for Core components at https://opensource.adobe.com/aem-core-wcm-components/library/container.html it appears there is a start of this approach as the image is being loaded with the coreimg selector:

<div class="cmp-container" style="background-image:url(image/_jcr_content/root/responsivegrid/demo_554582955/component/image.coreimg.jpeg/1561469321769/lava-into-ocean.jpeg);background-size:cover;background-repeat:no-repeat;background-color:#39CCCC;">

However, when I try this locally I dont actually get a URL rewritten to the coreimg selector, but rather the direct path to my image at /content/dam/path/to/my/image.jpg - is this because the online guide is using a sling mapping/rewrite for /content/dam paths? If so, is that standard practice and can that rewrite rule be shared?

Assuming the image does get written with the coreimg selector, how much effort do we think it would be to get background images using an appropriately sized rendition?

HitmanInWis commented 4 years ago

Looking at this more, its pretty simple to get a background image to render with coreimg selector by simply using the Image model to convert the image URL. The HTL would also likely need to render a data-cmp-widths property. I see data-asset and data-asset-id attributes as well, but I dont think those are used for adaptive imaging - perhaps Analytics. Lastly, we'd maybe need a data-cmp-is="bgimage" or something that JS could pick up on.

Once a BG image is rendered I think the changes would all be within /apps/core/wcm/components/image/v2/image/clientlibs/site/js/image.js. It would need to be able to update a background image URL similar to how the image src is updated today, keying off of the bgimage component type from data-cmp-is.

One challenge I see with this would be a viable noscript solution, but frankly I'm not overly concerned with that especially if we make the feature opt-in via configuration.

Anyone see any huge blockers to this beyond doing the legwork to code it up?

numirov commented 4 years ago

if am not mistaken policies should be there which would set allowed renditions, as AdaptiveImageServlet checks them. Or servlet could be enhanced so that in the case of bg image in the container it would read policy of the image component.