responsive-images | Responsive images solution without reflow | Blog library

Slightly contrived example...but it shows how to address an object with hyphens in the name.

I figured the solution. So if you want to use cropping for images with srcset you need to add relationship to srcset attribute like this:

The apostrophe-images-widgets module uses that double image technique specifically for when it contains multiple images and is acting as a slide show. That technique helps to maintain image appearance when the images are different sizes. That is why the apos-slideshow .apos-slideshow-item img CSS selector is hidden. The intention was that only the background-image would be visible.

As an aside, and as a member of the Apostrophe core team, I can tell you that this is an outdated strategy that we don't use anymore ourselves very often, if at all. But it's hard to remove or significantly change things like this once hundreds of sites are using it.

If you are making your own images widget (which would be a good idea), I would not use both the background-image wrapper and a normal img tag. Decide on which works best for your use case. There are still good reasons to use both (maybe other variations on a slider), but that depends on the project.

If your goal is to use the focal point tool, a normal img tag with a normal src attribute won't be enough. One way is to use a background-image attribute on an element that you have set the size for some other way (e.g., width and height styles) with the background-position using the focal point values. Another way is to use object-fit instead, with the focal point values in an object-position style.

You are dealing with two different types of options there, but they are both declared in the same place. focalPoint is a built-in option, enabling the focal point UI (which then lets you get focal point information back later) and sizesAttr is an example from the documentation of a custom option that you might create for your specific needs.

In both cases, they are passed into the area's widget options in the page or piece show page template. So this might be in default.html for a "default" page or show.html for a piece type's show page like so:

It occurred to me that it is better to use CSS variables and then read those values from javascript as documented here.

This has the advantages of

1. using the cascade to allow multiple regions of the page to each have their own vertical rhythm.
2. not requiring parsing the content of the ::after psuedo-element as JSON. The browsers are apparently inconsistent regarding how the escape embedding quotes in the content attribute.

One downside is that custom attributes are not as widely supported as pseudo elements. This way will break on more browsers. Because it's only cosmetic, I find that acceptable.

... do I need to first put them all in the same folder, then somehow move them into their proper files

There are a couple of ways you can configure your responsive_images task to direct the resultant files to different destinations...

Using the custom-dest property you could configure your responsive_images task as follows:

Unfortunately it seems there isn't a way to have an image with srcset default to its natural size, taking DPR into account. The sizes attribute, which defaults to 100vw if not set on an image with srcset, redefines the image's intrinsic width, and there doesn't seem to be a way to reset it without providing an explicit width yourself.

In my specific situation I discovered that we were already storing the user's DPR in a cookie, so server-side I've started setting the width attribute on images to the max width of the image divided by the user's DPR. This prevents the image from being displayed larger than the original size, and ensures that the image is sized appropriately for devices with high pixel densities.

Of course, you'll probably want to combine this with max-width: 100%; in your CSS to prevent the image from displaying larger than its container.

Example solution:

The current state of srcset is such that I am not entirely sure what you are looking for is a requirement.

This article by Jason Grigsby entitled State of Responsive Images in 2017 helps explain that while some of this ambiguity is by design to promote competition between browsers, some of this could probably be clarified better:

...the different behavior causes confusion. The most common question I hear is from people testing srcset in Safari and not seeing new images download as the viewport size changes.

There is nothing that says that the browser needs to download new images as the viewport changes. In fact, it probably doesn’t make sense to download a new image if the browser already has a larger version of it and can downsize it. So while this may be a feature and not a bug, we could do a better job setting expectations for developers.

In the meantime I would be wary of quoting full support for srcset just yet. In my recent experience it has been anything but.

In your options object of your responsive_images task add the following two options:

• name
• rename

Set the values of both properties (i.e. options) to false. For example: