Karol P. Kozak - blog

Images in Optimizely, part 3 - Responsive images in React

Fri, 10 Sep 2021 16:00:00 GMT

Please note that the article was written for EPiServer 11.X. EpiResponsivePicture itself was ported to .Net Core version of EPiServer, but npm package is not updated, so it won’t work with the latest EPiServer/Optimizely CMS. If you need the update of the package, please contact me here :)

In first part of the series, I’ve shown how to install and configure Forte.EpiResponsivePicture package for responsive, adaptive, automatically cropped images in EPiServer CMS. Here I demonstrate how to quickly make it achievable also in EPiServer-based SPA application or pages rendered with React.

Images in EPiServer

Part 1: Automatically cropped & resized responsive images
Part 2: Picture profiles
Part 3: Responsive images in React

To demonstrate this in practice, let’s continue on developing the portfolio website we started in previous article. We already have page type that represents a single project page — now it’s time for listing of all the projects on homepage. It’ll be implemented as React component, allowing to filter them by the categories:

Disclaimer: This is just a showcase for responsive images library and should be treated as so. It is not showing any design patterns, good practices in software development etc. Actually, most things are deliberately trivialized to simplify existing setup and minimize amount of boilerplate code needed to run the project and demo capabilities of the package.

Installation

I assume we already have React configured with ReactJS.NET, as it’s beyond of the scope of this article. For reference, you can look at ReactJS.net website or peek at full source code of project in this tutorial available on GitHub.

Before we start, install epiresponsivepicture-react via npm:

npm install --save epiresponsivepicture-react

This library contains implementation of <ResponsivePicture> component for React, being capable of rendering proper <picture> tag, then handled by ImageResizer we’re using for scaling images. It accepts following parameters:

model, containing all the properties of an image needed to render it:
- url to the image,
- width and height of original images,
- focalPoint chosen by editor for cropping,
- alt containing alternate text defined by editor.
profile, being a picture profile, ported 1:1 from its C# equivalent. It can simply be serialized instance of PictureProfile.

For ReactJS.Net to be able to use PictureProfile object directly serialized to props, it is needed to configure it in a way to use camel case property names. In ReactConfig, add following code:
ReactSiteConfiguration.Configuration
    .SetJsonSerializerSettings(
         new JsonSerializerSettings
         { ContractResolver = 
   new CamelCasePropertyNamesContractResolver(),
});
This article uses the same convention for all view models passed to React components.

Use of the package

First, create a new page type that will become a homepage of portfolio website.

[ContentType(GUID = "D8BC62BE-64F1-48A9-86D1-E14A7C43FB88", DisplayName = "Project list",
    Description = "Page listing all projects, grouped by categories")]
[AvailableContentTypes(Availability.Specific, 
    Include = new[] {typeof(ProjectPage.ProjectPage)})]
public class ProjectListPage : PageData
{
    [Display(Order = 10)]
    public virtual string Title { get; set; }
    
    [Display(Order = 20)]
    public virtual string Subtitle { get; set; }

    [Display(Order = 30)]
    [UIHint(UIHint.Image)]
    public virtual ContentReference MainImage { get; set; }
}

In a controller for this page, we get all its children and iterate over them, building a view model with image, link URL and title, that can be passed directly to picture React component.

public class ProjectListPageController : ContentController<ProjectListPage>
{
    private readonly IContentLoader _contentLoader;
    private readonly IUrlResolver _urlResolver;
    private readonly CategoryRepository _categoryRepository;

    public ActionResult Index(ProjectListPage currentContent)
    {
         var allProjects = _contentLoader.GetChildren<ProjectPage.ProjectPage>(currentContent.ContentLink)
                .Select(x => new ProjectTeaser(x.Title, BuildResponsiveImage(x.MainImage), x.Category
                    .Select(y => _categoryRepository.Get(y).Name)
                    .ToList(), _urlResolver.GetUrl(x.ContentLink)));

        return View(new ProjectListPageViewModel(currentContent, allProjects.ToList()));
    }
}

Model for image is built in BuildResponsivePicture method, and it simply creates an object with Url, Width, Height, FocalPoint and Alt properties from image content, needed by our picture component to be rendered:

private ResponsiveImageViewModel BuildResponsiveImage(ContentReference imageLink)
    {
        var image = _contentLoader.Get<Image.Image>(imageLink);
        if (image == null) return null;
        return new ResponsiveImageViewModel(_urlResolver.GetUrl(imageLink), 
        image.FocalPoint, image.Width,
            image.Height, image.Description);
    }

ProjectTeaser is a view model that represents single project card, and is virtually a simple object with couple of properties:

public class ProjectTeaser
    {
        // ctor omited for brevity

        public string Name { get; }
        public ResponsiveImageViewModel Image { get; }
        public IEnumerable<string> Categories { get; }
        public string Url { get; }
    }

As we have a view model, now proper React component can be implemented. Each project teaser renders a link, title and image — using component from library

import {PictureProfile, ResponsiveImageViewModel, ResponsivePicture} 
    from "epiresponsivepicture-react";
// --

private static renderProjectTeaser(
        x: ProjectTeaser, 
        profile: PictureProfile) {
    return <div className="teaser">
        <a href={x.url} title={x.name}>
            <div className="teaserImage">
                <ResponsivePicture model={x.image} profile={profile}/>
            </div>
            <h2>{x.name}</h2>
        </a>
    </div>
}

And that’s it! Now we only render filter buttons based on data from teasers, and filter visible teasers. Full component looks as following:

export class ProjectList 
    extends React.Component<{ 
            profile: PictureProfile, projects: ProjectTeaser[] 
        }, 
        { 
            selectedFilter: string | null 
        }
    > {
    constructor(props: any) {
        super(props);

        this.state = {
            selectedFilter: null
        }

        this.getFilters = this.getFilters.bind(this);
    }

    render() {
        const projects = this.props.projects;
        const filters = this.getFilters(projects);
        const teasers = projects
            .filter(x => (
                !this.state.selectedFilter) || 
                x.categories.indexOf(this.state.selectedFilter) >= 0)
            .map(x => ProjectList.renderProjectTeaser(x, this.props.profile));
        return <>
            {filters}
            <div className="teasers">   
                {teasers}
            </div>
        </>
    }

    private static renderProjectTeaser(x: ProjectTeaser, 
            profile: PictureProfile) {
        return <div className="teaser">
            <a href={x.url} title={x.name}>
                <div className="teaserImage">
                    <ResponsivePicture model={x.image} profile={profile}/>
                </div>
                <h2>{x.name}</h2>
            </a>
        </div>
    }

    private getFilters(projects: ProjectTeaser[]) {
        const categories = projects.map(x => x.categories)
            .reduce((x, y) => x.concat(y), []) // flatten
            .filter((value, index, self) => self.indexOf(value) === index); // distinct
        const filters = categories
            .map(x => (
                <button className={x === this.state.selectedFilter ? "active" : ""} 
                        onClick={() => this.setState({selectedFilter: x})}>
                    {x}
                </button>)

        return <div className="filters">{filters}</div>
    }

The only thing yet left to do is to render created component in .cshtml file of the Project List Page and make sure we call ReactJS .ReactInitJavaScript() in view or layout.

@model ResponsivePictureSample.Features.Pages.ProjectListPage.ProjectListPageViewModel

@* ... *@
<div class="content">
    <h1>@Html.PropertyFor(m => m.Content.Title)</h1>
    <h2>@Html.PropertyFor(m => m.Content.Subtitle)</h2>
</div>

@Html.ImagePropertyFor(m => m.Content.MainImage, PictureProfiles.HeaderImage)

<div class="content">
    @Html.React("ProjectList", new
    {
        profile = PictureProfiles.ProjectImagesGallery,
        projects = Model.Projects
    })
</div>
@* ... *@
@Html.ReactInitJavaScript()

After running application, creating a list page and few project pages as its children, we can see the homepage rendered with React, with images adapting to screen size:

Example implementation of the component is created for React. However, based on source code of <ResponsivePicture> component you should be able to do the same with any JS technology of your choice, by adjusting it to the way you’re rendering actual markup. The most important part of generating URL to the image, taking target width, height, cropping and focal point into consideration, is contained in VanillaJS getImageUrl function, so it can be easily used in a framework of your choice.

Images
https://unsplash.com/photos/NHLS5hOSH0c

Responsive images in Optimizely, part 2 - Picture profiles

Sun, 01 Aug 2021 19:30:00 GMT

We’re already running Image Resizer with EPiServerBlobReader and Forte.EpiResponsivePicture to render <picture> tags in Optimizely CMS (EPiServer), but the picture profiles we’re using are far from being optimal. What are these picture profiles, and how do they affect the images?

Responsive images in Optimizely CMS (EPiServer)

Part 1: Automatically cropped & resized responsive images
Part 2: Picture profiles
Part 3: Responsive images in React

What is a picture profile

Forte.EpiResponsivePicture package is based on EPiServerBlobReader plugin created by Valdis Iljuconoks, extending its functionalities with focal point base cropping and few other adjustments. The source package introduces the concept of picture profiles. Although its structure is a bit different, the purpose is pretty much the same as in source library.

A picture profile is an entity describing target size & quality of the rendered image. It can be perceived as the specific use case for the figure on the web page — for example header, image gallery, product card, article teaser, etc. Having well-defined profiles allow you to use the same image in almost all cases, always fine-tuned and cropped to fit its place.

An example picture profile looks as follows:

public static readonly PictureProfile ExampleProfile = new PictureProfile
{
    Format = ResizedImageFormat.Jpg,
    DefaultWidth = 800,
    Sources = new[]
    {
        new PictureSource()
        {
            AllowedWidths = new[] {360,  768, 1024, 1920},
            Mode = ScaleMode.Default,
            TargetAspectRatio = AspectRatio.Original,
            Sizes = new[]
            {
                "(min-width: 1024px) 50vw",
                "1000px"
            }
        }
    }
};

Each picture profile should define a set of sources, as well as the default width for an image. The default width is used when the browser doesn’t support picture spec, or no sources match their media condition). It can also optionally set the target image format.

The source has numerous properties to customize rendering:

Mode — One of Max, Pad, Crop, Stretch. Defines behavior when target dimensions don’t match original. Default is equal to Pad.
TargetAspectRatio — width to height ratio of output image. The most interesting when used with Crop mode, it then causes cropping image according to the focal point. When no cropping is desired, use AspectRatio.Original — original aspect ratio will be maintained.
Sizes — a list used to constraint image size with media condition. If you’re familiar with <picture> spec, this is virtually the same. Each size contains media condition followed by the desired size of image, in CSS units. px, vw/vh, em/rem supported. However, you cannot use %. Sizes are matching from the top, so the first matching condition will be applied. The last size may omit the condition — it will then be used as a fallback when no matching condition is found.
AllowedWidths — defines in which dimensions images should be available. It is used to generate srcset in resulting <picture>
Quality — for JPEGs, compression quality of output image.
MediaCondition optional media condition that constraints use of the source. When multiple conditions are met in different sources, first matching is taken.

How to write profiles?

Generally, a single source is capable of serving images in various sizes. You should use a separate source when different aspect ratios and/or mode used. For images with the same aspect ratio, it is better to have additional allowed width and handle it with sizes — for performance and bandwidth optimization reasons.

This is because browsers are optimizing loads. For example, when reducing the size of the browser window, there is no point in loading a smaller image, if the bigger one is already in cache. When having a bigger image, the browser won’t load a smaller one.

However, different <source> instructs the browser that images between sources are different — either differently cropped, or even totally different media. So resizing the browser window in a way that another <source> matches, will always trigger loading another image. Thanks to that, after switching you won’t have badly aligned, improper images shown in your mobile layout.

Handling Retina

Before <picture> spec being widely adopted, Retina screens used to be a headache — developer needed to write additional media query for 2x. If that’s too little, there are devices with the device pixel ratio greater than 2 (now even more than 3) and being fractional. For example, it is quite common that small laptops have enabled scaling on OS level, which in browser is seen as DPR like 1.25.

As in sizes we specify sizes of space that image occupies in CSS units, not the screen pixels, Retina displays are automatically handled. You just need to add image twice as wide to AllowedWidths (or whatever DPR you want to support best). Simple as that, the browser will do the rest.

Examples — sample portfolio project

To show all of this by example, let’s go back to the project we started implementing in the previous part and finally adjust its picture profiles. On the project page, there are three ways of displaying the image: header, inside the article, and bottom image gallery.

Header image

At first, let’s take the background header image. The header is styled to occupy 60% of viewport height and extend to full screen on mobile. Typically desktop wide screens are 16:9, so our resulting target aspect ratio will be

16:(9x0.6) = 16:5.4

Most typical screen sizes are 1920x1080, 1440x900, 1280x960(or 800). Desktop layout range ends at screens 1024px wide. Thus we can model source for desktop screens as follows:

new PictureSource()
{
    MediaCondition = "(min-width: 1024px)",
    AllowedWidths = new[] {1920, 1440, 1280, 1024},
    Mode = ScaleMode.Crop,
    TargetAspectRatio = AspectRatio.Create(16,5.4), // 60vh for 16:9 screens
    Sizes = new[]
    {
        "100vw"
    },
    Quality = 80
}

As on mobile we typically have a different screen aspect ratio, we’re covering this with another source. Dimensions of mobile screens differ, but the most “standard” would be vertically placed, panoramic screen (9:16). There is no way to cover each mobile device, so let’s go by choosing the most standard widths: 360px, 375px, 420px. DPR is usually 2x or 3x, so we add additional widths of 750, 1050 and 1125px — 375x2, 350x3 and 375x3 respectively. I think there is no point in loading overlayed background wider than 1125px on smartphones that fit into the pocket, so we stop at this size.

new PictureSource()
{
    AllowedWidths = new[] {360, 375, 425, 750, 1050, 1125},
    Mode = ScaleMode.Crop,
    TargetAspectRatio = AspectRatio.Create(9, 16),
    Sizes = new[]
    {
        "100vw"
    }
}

As the second source is our last one, we can skip having media condition for it. In both cases, the image always occupies the whole space, so the size is set to 100vw. We can also lower quality a bit, as image is being shown in the background, overlayed.

Finally, our new header image profile looks as follows:

public static readonly PictureProfile HeaderImage = new PictureProfile
{
    Format = ResizedImageFormat.Jpg,
    DefaultWidth = 1920,
    Sources = new[]
    {
        new PictureSource
        {
            MediaCondition = "(min-width: 1024px)",
            AllowedWidths = new[] {1920, 1440, 1280, 1024},
            Mode = ScaleMode.Crop,
            TargetAspectRatio = AspectRatio.Create(16,5.4), // 60vh for 16:9 screens
            Sizes = new[]
            {
                "100vw"
            },
            Quality = 60,
            
        },
        new PictureSource
        {
            AllowedWidths = new[] {360, 375, 425, 750, 1050, 1125},
            Mode = ScaleMode.Crop,
            TargetAspectRatio = AspectRatio.Create(9, 16),
            Sizes = new[]
            {
                "100vw"
            },
            Quality = 60
        },
    },
};

Article content

For the purpose of the article, we assume that we never want to crop the images. and always show them as an editor uploaded them. We can cover it with just one source. Maximum width of article content is 1140px.

public static readonly PictureProfile XHtmlString = new PictureProfile
{
    Format = ResizedImageFormat.Jpg,
    DefaultWidth = 800,
    Sources = new[]
    {
        new PictureSource
        {
            AllowedWidths = new[] {360, 480, 768, 1024, 1280, 1440},
            Mode = ScaleMode.Default,
            TargetAspectRatio = AspectRatio.Original,
            Sizes = new[]
            {
                "(max-width: 1480px) 100vw",
                "1440px"
            },
            Quality = 80
        }
    }
};

Project images gallery

Project images gallery seems most sophisticated. Desktop gallery shows 4:3 pictures in a three-column layout, while on mobile we want to generate square images in 2 columns. As you may see, it isn’t overcomplicated:

public static readonly PictureProfile ProjectImagesGallery 
    = new PictureProfile()
{
    Format = ResizedImageFormat.Jpg,
    DefaultWidth = 800,
    Sources = new[]
    {
        new PictureSource
        {
            MediaCondition = "(min-width: 1024px)",
            AllowedWidths = new[] {960,640,480,430,345},
            Mode = ScaleMode.Crop,
            TargetAspectRatio = AspectRatio.Create(4, 3),
            Sizes = new[]
            {
                "30vw"
            },
            Quality = 80
        },
        new PictureSource
        {
            AllowedWidths = new[] {215,375,525,640,960},
            Mode = ScaleMode.Crop,
            TargetAspectRatio = AspectRatio.Create(1, 1),
            Sizes = new[]
            {
                "50vw"
            },
            Quality = 80
        }
    }
};

That’s it! Now images are quite fairly optimized, and — when cropped — cut according to the focal point set by editors, looking pretty good in every scenario:

In the next part of the tutorial I’ll demonstrate how to combine Forte.EpiResponsivePicture with React by creating projects listing page.

The full source code of the sample project is available on GitHub.

Responsive images in Optimizely CMS - automatically resized & cropped picture

Thu, 01 Jul 2021 17:30:00 GMT

Responsive images in Optimizely CMS (EPiServer)

Part 1: Automatically cropped & resized responsive images
Part 2: Picture profiles
Part 3: Responsive images in React

As responsive websites must load quickly and offer good quality on all devices at the same time, it is almost obligatory to use HTML5 <picture> tag that allows providing different sets of images targeting a whole variety of screen sizes and pixel densities. In this series I’m showing how to make automatic, responsive pictures in Optimizely CMS (formerly EPiServer), which gets automatically scaled, compressed, or even cropped perfectly for the use case.

The <picture> tag is handy, but preparing each image in at least a few sizes is not the most attractive action that content creators can do. Additionally, computers are times better and faster in image processing (additionally, they don’t get bored at the same time) — so there is no reason to do that by ourselves.

What is Forte.EpiResponsivePicture

Valdis Iljuconoks had created great EPiServer plugin that allows automatic resizing of the images. It enables ImageResizer support for the content uploaded to the CMS. I also liked focal point-based cropping shown in the project developed by defsteph (currently archived), but neither of these two projects allowed fully adjusting image size or cropping based on visitor’s screen size.

Leveraging concept of picture profiles from Valdis’ package by mixing it with focal point cropping and ImagePointEditor by ErikHen had allowed to squeeze from the <picture> spec as much as possible!

Focal point

On one hand, we could allow editors to upload different images for all variants of layouts, but in reality, we usually don’t need completely different images for desktop and phone/tablet screens. In the vast majority of cases, all we want to do is just make the image cropped in a way that the most important part of the image is still shown. This part of the image is called its focal point. By allowing editors to choose that place on the image, we will be able to use the same image in very different scenarios, automatically cropped, and looking good at the same time on every device and use case on your page. No one likes boring, repetitive tasks, so if you take them off the editors, they’ll be really grateful!

Let’s take an example project to illustrate the idea — a site presenting the portfolio of fictional architects. We’re starting with a simple page that describes a project:

How to use

Disclaimer: The code shown in this article is meant to illustrate the idea and usage of the Forte.EpiResponsivePicture package and is not showing good practices of writing code. For the simplicity of this tutorial, some things are deliberately trivialized.

Full code of the project developed in this tutorial can be found on GitHub.

Installation

First, let’s install the package from NuGet feed from your IDE, or by running the command:

Install-Package Forte.EpiResponsivePicture

Warning: When installing via JetBrains Rider, make sure that static resources of peer dependency, ImagePointEditor, located in modules/_protected/ImagePointEditor, were added to the project correctly as <Content>, not <None> (see picture below).

Image content type & properties

Then, let’s create content type for an image, deriving from base image type in Forte.EpiResponsivePicture:

[ContentType(GUID = "FD23C075-1DCD-4EF9-9E60-505ACD34C211")]
[MediaDescriptor(ExtensionString = "jpg,jpeg,gif,png")]
public class Image : Forte.EpiResponsivePicture.ResizedImage.ImageBase
{
}

When introducing responsive pictures to an existing project and you can’t, or simply don’t want to derive from the base class, alternatively you can implement IImage and IResponsiveImage interfaces, for automatic alt loading from image metadata, and focal point based cropping, respectively. Width and Height properties are automatically set when publishing content, so they shouldn’t be editable. Although, base class has also the additional quality of being culture-specific, so you can prepare versions of alt for different language branches easily (this is greatly explained by Greg Wiecheć on his blog).

Responsive image as property on page

Our first page type will represent single project in portfolio of our architects:

[ContentType(GUID = "4CCD0094-450D-449F-8B51-D7FF7A5A249F", 
             DisplayName = "Project Page",
        Description = "Single project article")]
[AvailableContentTypes(Availability.None)]
public class ProjectPage : PageData
{
    [Display(Order = 0)]
    public virtual string Title { get; set; }
    
    [Display(Order = 10)]
    [UIHint(UIHint.Image)]
    public virtual ContentReference MainImage { get; set; }

    [Display(Order = 20)]
    public virtual XhtmlString Description { get; set; }
    
    [Display(Order = 30)]
    [AllowedTypes(typeof(Image.Image))]
    public virtual ContentArea Images { get; set; }
}

This page allows adding images in three different ways

as a ContentReference in MainImage,
as elements of ContentArea, for Images gallery,
in Description, added to XhtmlString via TinyMCE.

To render <picture> from content reference, we call ResizedPicture(ContentReference, PictureProfile) extension method of HtmlHelper:

<article>
    <div class="header">
        <div class="content">
            <h1>
                @Html.PropertyFor(m => m.Title)
            </h1>
        </div>
        @Html.ResizedPicture(Model.MainImage, 
            PictureProfiles.HeaderImage) <!-- rendering of the image -->
    </div>
    <div class="content description">
        @Html.PropertyFor(m=>m.Description)
    </div>
</article>

The second parameter of the ResizedPicture method is an instance of Picture Profile. PictureProfile is a class that represents single use case of an image, describing image dimensions, cropping, quality, etc. needed for that place, allowing to instruct the browser how the images should look like. These data are not related to the images themselves, rather describing a concrete place on a website for it. I’ll explain this concept, as well as how to create picture profiles, later. For now, let’s go with some placeholder:

public static class PictureProfiles
{
    public static readonly PictureProfile HeaderImage = new PictureProfile()
    {
        Format = ResizedImageFormat.Jpg,
        DefaultWidth = 800,
        Sources = new []
        {
            new PictureSource
                {
                    AllowedWidths = new[] {1920, 1440, 1280, 1024},
                    Mode = ScaleMode.Crop,
                    // 60vh for 16:9
                    TargetAspectRatio = AspectRatio.Create(16,5.4), 
                    Sizes = new[]
                    {
                        "100vw"
                    },
                    Quality = 60
                },
        }
    }; 
}

Now we can run the application, go to CMS edit mode, and create a new page for the project. Upload an image, remembering about filling alternate text and setting focal point, being the most important thing the photo is showing. Then, if we set the image as HeaderImage of our hero page, we can see that our image was rendered nicely as a <picture> element, and is adapting to screen dimensions changes. Also, alternate text was loaded from image properties in the proper language.

However, as we didn’t use @Html.PropertyFor, On-Page Editing doesn’t work for this property. To address that issue, we need to define a display template for properties marked with Image UiHint (for more info, Allan Thraen wrote a great post explaining how images are rendered in EPiServer (now Optimizely)). Let’s create a partial view in Views/Shared/DisplayTemplates, named Image.cshtml with model matching to our property type, that additionally tries to extract Picture Profile from ViewData:

@model EPiServer.Core.ContentReference
@{
    var pictureProfile = (ViewData["PictureProfile"] as PictureProfile) 
        ?? PictureProfiles.XHtmlString;
}

@if (ContentReference.IsNullOrEmpty(Model) == false)
{
    @Html.ResizedPicture(Model, pictureProfile)
}

Now we can render the image with .PropertyFor passing picture profile as additional view data. Let’s wrap this call with a handy extension method:

public static class HtmlHelperExtensions
{
    public static MvcHtmlString ImagePropertyFor<T, TValue>(this HtmlHelper<T> html,
        Expression<Func<T, TValue>> propExpr,
        PictureProfile pictureProfile)
    {
        return html.PropertyFor(propExpr,
            new {PictureProfile = pictureProfile});
    }
}

Now, after rendering the image with the following line, On-Page Editing works properly:

@Html.ImagePropertyFor(m=>m.MainImage, PictureProfiles.HeaderImage)

Rendering `<picture>` for Image in Content Area

Our project page looks great already. However, after adding some pictures in TinyMCE to the XHtml description field, it is still rendered as a regular <img> tag. Moreover, after adding some nice pictures to the Images Content Area, the page breaks completely, not knowing how to render the images! Let’s address the second issue first.

Let’s create a partial controller for our image type to make Optimizely (EPiServer) know how to render this type of content — exactly the same as we’d do with any content that can be rendered in the Content Area. The controller attempts to extract picture profile from ViewData of parent context. When profile is not present, it falls back to default XHtmlString profile — passing the data to Image.cshtml view defined in the previous step:

[TemplateDescriptor(
    Inherited = true, 
    Default = true,
    AvailableWithoutTag = true
)]
public class ImageController : PartialContentController<Image>
{
    public override ActionResult Index(Image currentContent)
    {
        var profile = ControllerContext.ParentActionViewContext
                         .ViewData["PictureProfile"] as PictureProfile
                        ?? PictureProfiles.XHtmlString;

        ViewData["PictureProfile"] = profile;

        return PartialView("~/Features/Image/Image.cshtml", currentContent.ContentLink);
    }
}

We still need to define XHtmlString picture profile:

public static readonly PictureProfile XHtmlString = new PictureProfile()
{
    Format = ResizedImageFormat.Jpg,
    DefaultWidth = 800,
    Sources = new []
    {
        new PictureSource()
        {
            MediaCondition = "max-width: 768px",
            AllowedWidths = new [] {360, 480, 768},
            Mode = ScaleMode.Crop,
            TargetAspectRatio = AspectRatio.Create(3,4),
            Sizes = new []
            {
                "95vw"
            }
        }
    }
};

Now in ProjectPage.cshtml we can finally render the content area containing images, passing specific profile in the additionalViewData parameter (let’s not bother the picture profile for now, we can use any of the existing as well):

@Html.PropertyFor(m=>m.Images, 
    new
    {
        PictureProfile = PictureProfiles.HeaderImage
    })

Picture in XHtmlString

The next thing that we still need to have worked out is rendering images dropped to the XHtmlField, edited via TinyMCE. By default, TinyMCE adds image dragged in the editor as <img>, allowing an editor to add custom classes and customize rendering. There are generally two ways of coping with that:

customize TinyMCE to add an image as a content block,
alter rendering process of XHtml fields and replace <img> tags with responsive <picture> element.

As the first solution is neat and simple, we’ll go with that one. We only need to add a custom UI Descriptor, altering drop behavior for Image content type:

[UIDescriptorRegistration]
public class ImageUIDescriptor : UIDescriptor<Image>, IEditorDropBehavior
{
    public EditorDropBehavior EditorDropBehaviour { get; set; }

    public ImageUIDescriptor()
    {
        EditorDropBehaviour = EditorDropBehavior.CreateContentBlock;
    }
}

When dropped, the image will be now rendered with partial controller and the view defined for Content Area. It is worth knowing that using “Insert/edit image” won’t result in the same, so we have to remove this button from toolbar to prevent users from something we don’t expect.

That’s it! We have made our responsive images work with the Optimizely CMS. The next part will show how to replace current placeholder picture profiles with the actual ones.

The whole source code of this tutorial can be found on GitHub.

Images:
1: Karolina Grabowska
2: SplitShire

How does the work?

Sat, 27 Mar 2021 10:30:00 GMT

HTML5 is knocking around for some time already. Actually, most of it was widely adopted, fairly quickly became a part of good practices, and later — almost mandatory for semantic and structured Web content. In general, it allows to specify more than one version of the image to be shown, and let the browser choose option that fits most. Almost every conscious web developer is aware of <picture> tag and knows that it solves a problem with responsive, optimized images in Web. While it may seem no-brainer, knowing exactly how that works and how browsers handle that is sometimes being treated as kinda’ witchcraft.

In good ol’ days of the Internet, everyone was browsing the Web with Internet Explorer (or earlier, Netscape Navigator), using desktop with screen having more-or-less the same resolution. However, starting from 1990s, more and more different resolutions appeared, and another types of devices got connected to the Internet, having now almost everything online. PCs. Smartphones. Tablets. Game consoles. TVs. Smartwatches. Even light bulbs (OK, I know — even if connected to the Internet, one can not browse the Web with light bulb. Yet.) All these devices coming with dozens of different models, combinations, screen sizes and resolutions. To make this hell worse, Apple introduced Retina displays a while ago. There is no longer possibility to have one-picture-to-rule-them-all. Kinda dark times for people trying to publish content in the Internet, right? Well, not really.

Controlling image dimensions: `srcSet`

It’s been some time when the <picture> was introduced, and as you see above, it is supported by all Internet browsers (I mean, browsers). Internet Explorer has some polyfills available, so if you still have to support this ancient artifact, there is an option. At worst, without polyfill, it would be fallbacked to what was defined in <img> tag.

First, let’s assume that we have image that takes full width of the article pane, up to 1000px. Wanting them to be shown good on Retina screens, we might do something like the following:

<picture>
    <source srcset="1000px.jpg 1x, 2000px.jpg 2x, 3000px 3x" />
    <img src="1000px.jpg" alt="Our beautiful image" />
</picture>

Adding a <source> element with srcset attribute, containing comma-separated list of URLs to different versions of the image, will instruct the browser to choose the one that fits best. In this case, for devices with device pixel ratio equal to 2, bigger image could be loaded. For device pixel ratio at 3, the biggest one will be loaded, making everything look fine on different screens.

However, this takes into consideration only pixel density — so, even browsing with the small Retina-like device will trigger loading bigger image unnecesarily. For example, with iPhone 6/7/8, working at CSS resolution of 375x667 and pixel density 2.0, we can take advantage of image being at most 750 pixels wide. The smallest one provided is sufficient, while device pixel ratio suggest to load image with dimensions multiplied by 2. Definitely not the best way to save bandwith. If we would want to do it better, we need to make calculations based on image placeholder size & breakpoints, and use media querying to adjust <source> elements accordingly. Additionally, we’re not optimally covering devices with pixel density values not being integer, or bigger than three (there are already some devices).

That’s why second option of providing image size alternatives — width descriptor — is much more fancy. Instead of constraining images to pixel density, let’s just describe the images we’re providing:

<source srcset="1000px.jpg 1000w, 2000px.jpg 2000w, 3000px.jpg 3000w" />

The above literally instructs browser that 1000px.jpg is 1000 pixels wide, 2000px.jpg — 2000 pixels, and 3000px.jpg — 3000 pixels.

Why is that better? We didn’t instruct the browser directly when certain images should be picked, but just let it to browser. We still need to give browser directions on how to choose it, but we won’t need to tie image sizes with media conditions, doing all the calculations and constraining loading proper images. Just imagine the scenario of whole-width-images-but-2-columns-on-tablet-and-4-on-desktop, and try to include all variety of pixel density. Yup. May by a bit messy. And let the one of you that won’t make a mistake during the calculations be the first to cast a stone.

OK, we did first part — told the browser what images we have. Now let’s add sizes to that. To make things more fun, let’s use that simple layout mentioned earlier:

on mobile, image is displayed full width
on tablets, show items in two column layout
4 columns for desktop,
whole content pane is growing up to 1400px at screen width of 1440px, then leaving margins on both sides.

While it might seem tough, actual markup is pretty straightforward:

<source srcset="340px.jpg 340w, 
                480px.jpg 480w,
                700px.jpg 700w, 
                1024px.jpg 1024w" 
        sizes="(min-width: 1440px) 340px,
               (min-width: 1024px) 22vw,
               (min-width: 768px) 45vw,
               92vw"
                />

We can see already known srcset, and a new attribute — sizes. Sizes describe widths of space held for the image, in CSS units. Note that w in srcset mean “pixels of image”, while px in sizes — “CSS pixels” (which not necessarily mean screen pixel).

Why is that better? Well, what we did was describing images we have (in image units), as well as space which these image should occupy (in CSS units), leaving all the calculations to browser. We don’t have to bother device pixel ratio, counting what should the image size be and so on. Additionally, we described both images and space for them in their natural units — image in pixels (of bitmap), sizes — with CSS px or vw, the units we use in CSS to same exact thing. So now, viewing the page with Retina iPhone with resolution (in CSS pixels) 375x667, with device pixel ratio equal to two, browser will look for image 690 pixels wide (375 * 0.92 * 2). The closest one is 700, so this one will be chosen.

What’s also worth noting:

if multiple media conditions are met, first (top) matching size is taken — this might be a bit counterintuitive, as with CSS, selectors weighted equally are applied sequentially
despite above example uses px or vw, you can use any CSS unit (vh, em, rem), or even calc. I prefer to simplify things so usually go with simple approximation that is fair enough, but value accurately calculated with calc will also do the job. However, percents cannot be used.

Alternative images for different views (aka art direction-based selection): `<source>` and `media`

While srcset and sizes address our needs for different image quality across screens, it doesn’t help when our layout changes significantly across devices. Let’s suppose we have nice, beautifully composed, horizontal product photo, that shows your product with great surrounding on desktop. However, with the same photo on vertical, 4-inch smartphone screen, customer will barely see the product. We need to show something more accurate.

To achieve this, just create separate <source> element with media attribute describing when to use each image:

<picture>
    <source media="(min-width: 1024px)" 
            srcset="nicely-composed-medium.jpg 1024w, 
                    nicely-composed-large.jpg 1440w"
            sizes="100vw"/>
    <source srcset="bare-product.jpg 375w, 
                    bare-product-retina.jpg 750w"
            sizes="100vw"/>
    <img src="default.jpg" alt="My beautiful product" />
</picture>

elements allow to show totally different images depending on screen size">

While this might seem a bit similar to use of srcset and sizes, the main difference is that by using different <source> you instruct the browser that another image is used, and it’s not only another sizing of the same — so, for example, resizing the screen down will force loading the new image if another <source> meets its criteria. This wouldn’t happen with srcset, as browser won’t load smaller image already having bigger version of the same pic.

Different image formats

Another nice feature of <source> is possibility to serve images in different formats. For example, if we want to allow using webp images for browsers supporting it, just add type=webp attribute:

<picture>
    <source srcset="image.webp" type="webp" />
    <source srcset="image.jpg" type="jpeg" />

    <img src="default.jpg" alt="Alternate text" />
</picture>

Guess that’s rather self-explanatory, so no need to explain.

That’s it!

With <picture> tag, responsive, adaptive images are becoming ridiculously simple, especially combined with solutions that can do the job of resizing and/or cropping automatic. It is supported virtually everywhere, and it’s worth to be used in nearly every web page.

Using Optimizely CMS (formerly EPiServer)? The solution already exists.

Images:

1: Pine Watt
2: Pixabay
3: Tom Swinnen
3: Mali Maeder
5: caniuse.com

Karol P. Kozak - blog

Images in Optimizely, part 3 - Responsive images in React

Images in EPiServer

Installation

Use of the package

Responsive images in Optimizely, part 2 - Picture profiles

Responsive images in Optimizely CMS (EPiServer)

What is a picture profile

How to write profiles?

Handling Retina

Examples — sample portfolio project

Header image

Article content

Project images gallery

Responsive images in Optimizely CMS - automatically resized & cropped picture

Responsive images in Optimizely CMS (EPiServer)

What is Forte.EpiResponsivePicture

Focal point

How to use

Installation

Image content type & properties

Responsive image as property on page

Rendering <picture> for Image in Content Area

Picture in XHtmlString

How does the work?

Controlling image dimensions: srcSet

Alternative images for different views (aka art direction-based selection): <source> and media

Different image formats

That’s it!

Rendering `<picture>` for Image in Content Area

Controlling image dimensions: `srcSet`

Alternative images for different views (aka art direction-based selection): `<source>` and `media`