Picture - a new element that does not exist
In the development builds of the Chrome, Firefox, and Opera browsers, support has been added for a new element
picturedesigned to solve a number of problems that arise when developing responsive designs. Let's take a closer look at it.
The new element
picturesolves the following tasks facing the developer of adaptive web applications (I will use the classification proposed by pepelsbey at one of the recent front-end conferences):
- R etina, i.e. screens with a density of dots per inch 150 and above on which the usual image looks blurry
- And adaptability, the task of resizing the image according to your rules prescribed in the design, depending on the size of the viewport.
- F : The format, the ability to use modern formats such as WebP, if they are supported by the browser
- By adrirovanie or artistic purpose. Crop unimportant parts of the image when displayed on devices with a smaller screen.
Adding the first letters, we get the mnemonics of the RAFK
Conditionally, the expanded syntax of the new element looks like this
picturedoes not render any content, but only serves as a reference container for the tag embedded in it
Therefore, for most tasks, an abbreviated recording is enough, without using
" ]="" [sizes="<ваши размеры в зависимости от раскладки>">
Let's look at how the above problems are solved with the help of a new element. All sample files can be found in this repository github.com/fetis/picture
To test the examples from this article on the desktop, you will need either Firefox Nighlty (support is
pictureenabled by setting
dom.image.picture.enablein about: config), or Chrome Canary , or Opera Developer . On a mobile device, a new item can be tested in Chrome Beta
We have an image of 400x300 pixels, which we also want to show beautifully at double and triple pixel density. To do this, prepare 2 more pictures, sizes 800x600 and 1200x900 and write the following code
3xthese are descriptors of pixel densities , they tell the browser that these pictures were prepared for this density, you can use it if you want. Please note that they do not force the browser to use these pictures, but only prompt it. The final decision remains with him depending on other conditions, for example, the current connection. In this case, the
srcserves as a source of the image for density <2 and a fallback in case the browser does not support the new element.
Imagine a layout in which there is a single breakpoint of 700px. If the viewport size is more than 700 pixels, we show the sidebar on the right and the size of our image should be 75% of the screen width. Otherwise, the sidebar is located at the end of the page and the image should be stretched to the full width. This is implemented by the following code
400w, 800w, 1200w- these are width descriptors , they tell the browser a picture of how wide it is at a given URL, and based on this information, the browser decides which image is best for the current situation. As in the case of retina, the information is advisory in nature and the final decision as to which image to load remains with the browser.
The simultaneous use of density and width descriptors is not allowed.
sizeslists the image sizes for all control points in our design. Control points are set in the form of a regular media expression, the browser takes the first one that returns True and does not further examine the chain. The new unit of length vw is used for the width value., which returns the value as a percentage of the width of the viewport.
If for the picture there is no need to use control points, then the record can be reduced to such
sizes="100vw". And for more complex designs, you can use the CSS function
calc(), for example, the
sizes="(max-width: 30em) 100vw, (max-width: 50em) 50vw, calc(33vw - 100px)"
Most difficult attribute in behavior in my opinion. If not specified
sizes, then the browser always chose the largest picture. In combination with
widthdoes not work, although it would seem a logical combination and a number of other glitches. Perhaps these are features of an early implementation.
As you can see, we have already covered 80% of the needs of adaptive layout, and have never used it
picture, it is time for him to enter the game too.
Using different formats for images is not much different from the methods used for tags
We provide a list of sources and mime / type for each, and the browser already selects the first one that knows. The image from the attribute is used as a fallback
When we show a photo on a smaller screen, sometimes it makes sense to crop off unnecessary details, leaving only the main part. The attribute will help us to cope with this task.
In each attribute
mediawe specify a media expression in which the original image will change and, unlike the previous examples, the browser will be required to follow it. Also note how cropping is combined with adaptability to stretch the image to its full width.
And now all 4 methods in one bottle :) Perhaps this will look like inserting pictures in a couple of years (an example from the Opera blog)
It uses 2 JPEG and WebP formats. With a screen width of more than 1280 pixels, a full-size picture of half the viewport is displayed. With a width of 640 to 1279, a cropped photo is shown at 60% of the width of the viewport. When the screen width is less than 640px, the cropped photo is displayed at 100% width. The selection for the current DPI of the screen is based on the width of the source files.
Browser support caniuse.com/#search=picture
Working group and typical tasks that they solved with the new responsiveimages.org element
Many examples of dev.opera.com/articles/responsive-images usage