Innovative design
The birthday present to Steps was an innovative, reduced design of the website www.steps.ch. The appearance is now completely responsive and therefore usable on mobile phones, tablets as well as at home on the desktop.

Challenging implementation
The implementation of the new design was particularly challenging in the development, as the new appearance consists of several micro animations. This also applies to the current date change in the schedule.

New CMS
The basis of the website was also renewed in the project: Steps now runs on the Sitecore Content Management System.

Cross-agency cooperation
The new Steps appearance was created in close cooperation with Migros in Lead, Y7K as design agency, Namics for the technical implementation in CMS and Liip for the front-end implementation.

After each optimization I thought that I understood how the srcset and sizes attributes of the <img> tag works. But each time, I made some new findings about how these attributes really work and where I need to take care while implementing them. Since there are lots of things you should know before using srcset I thought it could be useful to summarize the most tricky parts in a blog post.

A short introduction

I think most of you already heard of responsive images and especially the srcset attribute. But to be on the same page I still would like to start with a short introduction about these two attributes:

srcset

The srcset attribute is listing different resolutions of the same image from which the browser chooses the best fitting image source before loading it.

Example: srcset="ninja-1000w.jpg 1000w, ninja-500w.jpg 500w, ..."

To calculate this, the browser assumes the image fills up the full viewport width (100vw) by default, which means it uses the full width of the browser.

sizes

To tell the browser how much space the image really needs on our viewport, we can use the sizes attribute. This attribute contains a comma separated list of one or more image widths for different viewport sizes.

Each entry is a combination of a media condition and a width. Both of these values are described in CSS pixels so we don't need to care about device pixel ratio for this. If the media condition is omitted it evaluates to true automatically (= fallback). The sizes attribute gets read from left to right. As soon as a media condition evaluates to true the width of this entry is used. So be sure to order your values correctly!

Example: sizes="(min-width: 1000px) 50vw, 100vw"

The example above tells the browser that if the viewport is at least 1000px wide the image fills 50% of the space. If the browser is smaller, the image uses 100% of the available width.

If we combine the above two examples in an <img> tag and request it with a (1x/non-retina) browser the result would be the following:

• Browser width: 500px -> Matching sizes width: 100vw -> Needed image size: 500w -> Chosen image: ninja-500w.jpg.
• Browser width: 900px -> Matching sizes width: 100vw -> Needed image size: 900w -> Chosen image: ninja-1000w.jpg.
• Browser width: 1000px -> Matching sizes width: 50vw -> Needed image size: 500w -> Chosen image: ninja-500w.jpg.

Sizes affect how the image is shown

The first thing which is important to know about the sizes attribute is that it isn't only used to calculate the needed size, it is used as the rendered width of the image if the width is not defined in CSS too.

This means as soon as you add the srcset attribute to the <img> element the image might be displayed differently.

The reason for that is when you add the srcset attribute and omit the sizes attribute, the browser uses the default value for it, which is 100vw.

Here's an example (https://codepen.io/tschortsch/pen/LeMmyO):

As you can see, the browser stretches the image always to the matching size in the sizes attribute, as long as the width is not defined in CSS.

This leads us to Rule #1: Always set the sizes attribute if you use srcset. If sizes is omitted it defaults to 100vw.

How the browser selects the needed image size

Short answer: We can't tell.

Long answer: Every browser has a slightly different implementation which can change with every version of the browser. This leads to Rule #2: Never assume which image size the browser will choose.

The browser just chooses the best matching image for the current size. But if the browser finds a cached version of an image from the current srcset which is bigger than the needed size it prioritizes the image from the cache for example.

This makes it really hard to debug a srcset. To avoid the loading of cached files you should always debug srcsets in your browsers privacy mode.

As a result of this, it is possible that you have two exact same devices (same screen and browser size) but you get a different image size in both browsers.

Another really important takeaway from this brings us to Rule #3: A srcset should only contain images of the same ratio.

Since you can't really decide which image is loaded in which browser size you can't use srcset to serve different images on different sizes a.k.a. art direction (eg. 1:1 image on smaller devices, 2:1 image on larger devices). If you would like to do this you should use the <picture> element.

Pitfalls of the width ('w') descriptor

The width (w) descriptor of the srcset attribute has also some things which should be taken care of. First of all Rule #4: The width (w) descriptor should always match the images natural width. This means if the image has a width of 500px the width (w) descriptor should be exactly 500w. This sounds pretty easy to achieve but there are use cases where this isn't as easy.

Think of the following example: You load your images through a CDN, where you predefine all the sizes that should exist of an uploaded image. In the template you define a srcset with all of those predefined sizes. If you do not enable upscaling (on CDN side) and upload an image which is smaller than the biggest defined size, you will get an image which doesn't fit the width (w) descriptor in your template.

If this is the case you can get unexpected results. Let's look at this example (https://codepen.io/tschortsch/pen/rpoXvW / The problem in the example only occurs with screens that have a DPR >= 2):

If you don't have a display that has a DPR >= 2 here's a screenshot of what would happen if you had:

What is showed in the example above? As long as we don't define a CSS width, the image (which is originally 400px wide) doesn't fill up a container which is only 300px wide.

Let me explain what's happening here: We have an image container which is 300px wide. The image has a srcset with two possible image sizes: 300w, 600w. The 300w image has a natural width of 300px (correct). But since the original image has a width of 400px the 600w doesn't return an image which is 600px wide but the original 400px image (wrong).

If this container gets loaded with a DPR >= 2 the browser requests the 600w image (2 * 300px). Since the browser doesn't know that the image behind this descriptor is smaller than 600px it displays it as it would be that size. This means it gets squeezed to half of its size (400px / 2 = 200px). And that's why we end up with this strange situation that the image (which is originally 400px wide) doesn't fill the whole 300px image container.

When we enforce the image width in CSS, like we do in the 2nd example, the (400px) image gets stretched again to fill the 300px container and everything looks like expected.

And here we are with the Rule #5: Always enforce the image size in CSS when using srcset.

Wrap up

As you see responsive images have some parts, you should know when implementing them. Let's quickly go through our rules again:

• Rule #1: Always set the sizes attribute if you use srcset. If sizes is omitted it defaults to 100vw. Since the sizes attribute has an influence on how the image is displayed, it should never be omitted. If you do so, the browser uses the default value of 100vw.
• Rule #2: Never assume which image size the browser will choose. The reason for this is, that all browsers have slightly different implementation on how the correct image from a srcset is chosen. This implementation should be a black box for us, because it can change with every update.
• Rule #3: A srcset should only contain images of the same ratio. As a result of rule #2 we never know which image is loaded by the browser. To get the same result for all visitors every image in the srcset needs the same ratio.
• Rule #4: The width (w) descriptor should always match the images real width. The browser uses the width (w) descriptor to calculate how it should display the image. If it doesn't match the real width, we can get unexpected behaviour.
• Rule #5: Always enforce the image size in CSS when using srcset. Since there are some use cases where rule #4 can't be achieved, we should always enforce the width of an image in CSS.

Further resources

There are some really good resources to learn more about responsive images:

• Responsive images on Mozilla Developer Network: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images
• Responsive images on CSS-Tricks: https://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/
• Very nicely done introduction about srcset and sizes: http://ericportis.com/posts/2014/srcset-sizes/
• <img> Element documentation: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img

Liip has supported the Migros Group on the basis of a preliminary study, first wireframes and the CI/CD to design the new online career portal, to design it interactively and visually as well as to implement it technically. "One of the biggest challenges in the project was to map the complex group structure of Migros in a way that was easy for the user to understand," says Product Owner Martin Meier at Liip. The solution to this problem was, among other things, user testing of an early wireframe prototype and a consistent focus on the user on both the visitor and editorial side. Although the "Migros Gruppe Arbeitswelt" hosted more than 60 cooperatives and companies at the launch and the content was created by a correspondingly large number of teams, a very high degree of visual and structural consistency can be ensured through the site. This is made possible by a flat information architecture and numerous content modules that automatically adapt to the respective context. This gives cooperatives and companies sufficient flexibility and scope to optimize their new career site.

The new online platform was implemented together with the Migros Group deliberately following an agile approach. The continuous optimization during the course of the project enabled us to develop a high quality product, which already comes with extensive functions in the first release. The focus is on the search function for 600 jobs per month and the 1500 additional apprenticeships advertised each year, which is extremely efficient and flexible due to the modern Vue.js frontend architecture. For content management, the open source system Drupal 8 was chosen. In summary, Micol Rezzonico, Head of the Competence Center Employer Branding, says: "Together with Liip, we have succeeded in building a clear and stable platform that can be developed further on a modular basis and gives the Migros Group the opportunity to make its extraordinary diversity and the many qualities in the field of career accessable".

Responsible at the Migros Cooperative Association: Micol Rezzonico (Head of Competence Center Employer Branding), Christopher Schmidt (Project Manager), Pascal Schwager (Product Owner), Sabina Del Grosso (Content Strategy), Ivan Ganarin (Information Architect); Responsible at Liip: Martin Meier (Product Owner, Consultant), Jan Hug (UX Designer, Developer), Jonathan Minder (Developer), Krisztian Kovacs (Developer), Christian Wüthrich (Developer), Christian Stocker (Developer), Fabian Ryf (SEO/Analytics), Daniel Frey (Scrum Master), Tonio Zemp (Consultant).

Link to the Migros Gruppe Arbeitswelt: www.migros-gruppe.jobs

Now that all the videos of the Fronteers talks are online, I wanted to shared with you what I came back with, so that you also go benefit from this resource.

The Venue

I have been to some conferences, but this venue just rocked them all. We were hosted in the Pathé Tuschinski movie theater in the middle of Amsterdam. The pictures I took of this place describe how perfect this place was, much better than I could explain it with words:

The Lineup

The lineup of speakers was pretty impressive. Paul Irish, Jeremy Keith, Nicholas Zakas, Robert Nyman, Christian Heilmann, Stoyan Stefanov to name some of them. A whole bunch of wise guys. It was a blessing to listen to what they had to share.

The topics

CSS3 , javascript and of course everything around HTML5 were the trending topics. Lately, I somehow got an overdose of hearing about HTML5 everywhere again. But those speakers all presented their stuff with their own perspective and that made it really pleasant and inspiring to follow.

Jeremy Keith, for example, took us through the design principles on which HTML5 is built. I am still fascinated on the vision behind this standard. I truly believe such principles are what made the current standard a success and what will ensure its future.

Håkon Wium Lie, CTO of opera and long time member of the CSS working group went with us through the new features of CSS3 . He shared some pictures and anecdotes of the times he spent with Tim Berners Lee in the CERN, about 20 years ago, to illustrate what was inspiring them while creating the concept of CSS.

Meagan Fisher and Jina Bolton gave us their web designer perspective. Meagan showed us how she uses the new CSS3 properties to give even a better look to her designs on browsers that support them. Jina told us about the workflow she goes through while writing CSS.

I'm not a designer, but I envy their talent and creativity. A journey in a mind of such designers was a real gift to me.

I think you got the point and I won't comment every talk as you can find them online. Let me just recommend three of them to start with.

The 3 talks you should see

“ Progressive Downloads and Rendering” by Stoyan Stefanov

If you care at lot about performance for high traffic websites this is the talk to watch. Probably the talk where I learnt the most.

“ Reusable Code, for good or for awesome!” by Jake Archibald

Jake talked about how to design an API and making sure it's reusable. He mostly uses javascript as example, but the principles he presents (and which I cherish too) are relevant to any coding environment. The bonus of this talk is how entertaining that guy is.

“ Reasons to be cheerful” by Chris Heilmann

This is THE talk I would recommend to everyone working for the web. For about an hour he tells us why we have one of the most awesome jobs in the world. I enjoyed sitting there and contemplating his speaker talent delivering all the reasons why I do this job.