Responsive images in practice (Part 1)
Part 2
Part 3
Sixty-two percent of the data on the network is images, and every day we create more and more bytes of images. It would be amazing if they were all used for their intended purpose. But on small screens or on low resolution screens, most of this data turns into junk .
Why? Even in spite of the fact that the Internet was created in such a way that anyone could get access to it, through anything, only recently a variety of devices reached the level to provoke a large-scale movement towards responsive design. When we create responsive designs, our content is elegantly and efficiently integrated into any device. All our content, with the exception of raster images. Raster images have a fixed resolution. Their vessel — its reverend, with its sadly lonely src — cannot adapt.
Faced with a choice - either to make the pages blurred for some or slow for everyone - most designers choose the latter option, sending to everyone images designed to fill huge, high-resolution screens. That is, trash.
')
But! After three years of controversy, several markup elements appeared that could solve the problem with responsive images:
• srcset
• sizes
• picture
• and our old friend source (taken from the audio and video tags)
These new elements and attributes allow us to mark up, modify and present to each client the source code that suits him best. They made their way into the official specifications and their first full implementation - in Chrome 38, released in September. With their elegant reduction in requirements and polyfilling to reduce the gap, we can and should start using responsive images now. Therefore, let's start!
Let's take an existing web page and make images on it responsive. This can be done in three stages, applying each new markup element in turn:
1. Make our images scale efficiently using srcset and sizes.
2. We direct our images using picture and source media.
3. We provide an alternative image format using the picture and source type.
In the process, we will see for ourselves how much new features improve performance.
Status quo
As our object, we will take a small page about patchwork quilts. This is a simple responsive page. Here is some content: just huge images (blankets!). We want to show both the overall design of each blanket and as many complex details as possible. Therefore, for each blanket, we present two images:
1. General view of the blanket, tailored to the width of the paragraph.
2. A detailed image that takes up 100 percent of the screen width.
How would we set the size and mark up our images without new markup elements? First, the whole blankets. To make sure that they will always look clear, we need to determine the maximum allowable size of their layout. Here is an example of CSS:
We can calculate the maximum width of the img display by taking the maximum width (max-width) of the image (figure), removing the padding from it and converting “em” into pixels:
Or we can cheat and look into the developer tools:
(I prefer the second method.)
In any of the ways we get the maximum display width img of the whole blanket at 620 pixels. We will make our original image twice as large to fit twice the size of the screen - 1240 pixels wide.
But what about our detailed images? They stretch to fill the entire width of the window, the size of which does not have a fixed upper limit.
Let's pick up a bigger standard for it and increase, say, to 1920 pixels wide. When we display our images in such sizes, our page becomes quite “heavy” and weighs 3.5 MB. All, with the exception of 5.7 KB, here are images. We can guess that the many bytes of such images make up an invisible surplus when displayed on small screens with low resolution - but how much? Let's see.
Stage One: Scaling with Scrset and Sizes
The first problem we will face is to make the images scale effectively to any window width and screen resolution. We will try on several resolutions of our image in order to be able to selectively send huge sources to huge screens and / or high resolution screens, and more compact versions for everyone else. How? Using srcset.
Here is one of our detailed images for the entire width of the window:
The first thing you need to pay attention to with respect to img is that it still has src, which will be loaded in browsers that do not support the new syntax.
For more functional clients, we added something new: the srcset attribute, which contains a comma-separated list of source URLs. After each URL, we write the “width characteristic”, which indicates the width of each image in pixels. Is your image 1024 x 768 in size? Put 1024w after its URL in srcset. Browsers that support srcset will use these widths in pixels and all they know about the current viewer environment is to choose which source to download.
How do they choose? That's what I love most about the srcset attribute: we don't know! We can not know. The logic of selection is not specifically disclosed.
The first proposed solutions to the problem of responsive images tried to give the authors more control. We would be responsible for creating comprehensive sets of media queries - action plans that list all combinations of screen sizes and resolutions, with the source code tailored to each of them.
Srcset protects us from ourselves. Detailed control is still available when we need it (more on that later), but most of the time we’d better remove our hands from the keyboard and give the browser freedom. Browsers have a wealth of screen, window, connection, and parameter knowledge. Yielding control (by describing our images, instead of assigning specific sources for thousands of variations), we allow the browser to use this knowledge. We get the best (future-oriented) functionality with significantly less code.
Part 2
Part 3
Sixty-two percent of the data on the network is images, and every day we create more and more bytes of images. It would be amazing if they were all used for their intended purpose. But on small screens or on low resolution screens, most of this data turns into junk .
Why? Even in spite of the fact that the Internet was created in such a way that anyone could get access to it, through anything, only recently a variety of devices reached the level to provoke a large-scale movement towards responsive design. When we create responsive designs, our content is elegantly and efficiently integrated into any device. All our content, with the exception of raster images. Raster images have a fixed resolution. Their vessel — its reverend, with its sadly lonely src — cannot adapt.
Faced with a choice - either to make the pages blurred for some or slow for everyone - most designers choose the latter option, sending to everyone images designed to fill huge, high-resolution screens. That is, trash.
')
But! After three years of controversy, several markup elements appeared that could solve the problem with responsive images:
• srcset
• sizes
• picture
• and our old friend source (taken from the audio and video tags)
These new elements and attributes allow us to mark up, modify and present to each client the source code that suits him best. They made their way into the official specifications and their first full implementation - in Chrome 38, released in September. With their elegant reduction in requirements and polyfilling to reduce the gap, we can and should start using responsive images now. Therefore, let's start!
Let's take an existing web page and make images on it responsive. This can be done in three stages, applying each new markup element in turn:
1. Make our images scale efficiently using srcset and sizes.
2. We direct our images using picture and source media.
3. We provide an alternative image format using the picture and source type.
In the process, we will see for ourselves how much new features improve performance.
Status quo
I guess I don’t care so much about being old as being fat and old
Benjamin Franklin (or was it Peter Gabriel?)
As our object, we will take a small page about patchwork quilts. This is a simple responsive page. Here is some content: just huge images (blankets!). We want to show both the overall design of each blanket and as many complex details as possible. Therefore, for each blanket, we present two images:
1. General view of the blanket, tailored to the width of the paragraph.
2. A detailed image that takes up 100 percent of the screen width.
How would we set the size and mark up our images without new markup elements? First, the whole blankets. To make sure that they will always look clear, we need to determine the maximum allowable size of their layout. Here is an example of CSS:
* { box-sizing: border-box; } body { font-size: 1.25em; } figure { padding: 0 1em; max-width: 33em; } img { display: block; width: 100%; } We can calculate the maximum width of the img display by taking the maximum width (max-width) of the image (figure), removing the padding from it and converting “em” into pixels:
100% <img> width x ( 33em <figure> max-width - 2em <figure> padding ) x 1.25em <body> font-size x 16px default font-size = 620px Or we can cheat and look into the developer tools:
(I prefer the second method.)
In any of the ways we get the maximum display width img of the whole blanket at 620 pixels. We will make our original image twice as large to fit twice the size of the screen - 1240 pixels wide.
But what about our detailed images? They stretch to fill the entire width of the window, the size of which does not have a fixed upper limit.
Let's pick up a bigger standard for it and increase, say, to 1920 pixels wide. When we display our images in such sizes, our page becomes quite “heavy” and weighs 3.5 MB. All, with the exception of 5.7 KB, here are images. We can guess that the many bytes of such images make up an invisible surplus when displayed on small screens with low resolution - but how much? Let's see.
Stage One: Scaling with Scrset and Sizes
The first problem we will face is to make the images scale effectively to any window width and screen resolution. We will try on several resolutions of our image in order to be able to selectively send huge sources to huge screens and / or high resolution screens, and more compact versions for everyone else. How? Using srcset.
Here is one of our detailed images for the entire width of the window:
<img src="quilt_2-detail.jpg" alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." /> //quilt_2-detail.jpg 1920 . , , : <img srcset="quilt_2/detail/large.jpg 1920w, quilt_2/detail/medium.jpg 960w, quilt_2/detail/small.jpg 480w" src="quilt_2/detail/medium.jpg" alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork."> The first thing you need to pay attention to with respect to img is that it still has src, which will be loaded in browsers that do not support the new syntax.
For more functional clients, we added something new: the srcset attribute, which contains a comma-separated list of source URLs. After each URL, we write the “width characteristic”, which indicates the width of each image in pixels. Is your image 1024 x 768 in size? Put 1024w after its URL in srcset. Browsers that support srcset will use these widths in pixels and all they know about the current viewer environment is to choose which source to download.
How do they choose? That's what I love most about the srcset attribute: we don't know! We can not know. The logic of selection is not specifically disclosed.
The first proposed solutions to the problem of responsive images tried to give the authors more control. We would be responsible for creating comprehensive sets of media queries - action plans that list all combinations of screen sizes and resolutions, with the source code tailored to each of them.
Srcset protects us from ourselves. Detailed control is still available when we need it (more on that later), but most of the time we’d better remove our hands from the keyboard and give the browser freedom. Browsers have a wealth of screen, window, connection, and parameter knowledge. Yielding control (by describing our images, instead of assigning specific sources for thousands of variations), we allow the browser to use this knowledge. We get the best (future-oriented) functionality with significantly less code.
Part 2
Useful Paysto solutions for Habr readers:
→ Get paid by credit card right now. Without a site, PI and LLC.
→ Accept payments from companies via the Internet. Without a site, PI and LLC.
→ Acceptance of payments from companies for your site. With document circulation and exchange of originals.
→ Automation of sales and service transactions with legal entities. Without intermediary in the calculations.
→ Accept payments from companies via the Internet. Without a site, PI and LLC.
→ Acceptance of payments from companies for your site. With document circulation and exchange of originals.
→ Automation of sales and service transactions with legal entities. Without intermediary in the calculations.
Source: https://habr.com/ru/post/244175/
All Articles