This paper introduces some small knowledge points related to the adaptive application strategy of responsive images, the principle of backtracking, the color changing skills of SVG, the calculation formula of percentage positioning of Sprite diagram, etc., in order to help some students quickly clarify the idea of image application, as well as some application skills of Web images.
1. Application and rollback of responsive images
Features: simple application, easy to use, good performance Difficulty: LazyLoad implementation
According to the responsive images used by different devices, different resolutions and different pixel ratios, there are two commonly used scenarios:
1.1 Fixed size image
Based on device pixel ratio selection, many website logos are an example of fixed-width images that remain the same width regardless of viewPort width.
The following is an example of how images in dom and CSS are written
<img srcset="test.jpg 1.5x, test2.jpg 2x" SRC ="test.jpg" Alt ="" />Copy the codebackground-image: image-set(url(test.jpg) 1x,url(test2.jpg) 2x);Copy the code1.2 Image without fixed size
There are two common ways to handle content-related images, which are not always the same size when they need to be responsive and change with the viewport
1.2.1 We use srcset with w descriptor and sizes attribute.
The W descriptor tells the browser the quality of each image in the list. The sizes property is a comma-separated list of two values. According to the latest specification, if any image in the SRCset uses the W descriptor, then the sizes property must be set.
The sizes property has two values: the first is a media condition; The second is the source image size value, which determines the width of the image under certain media conditions.
Such as:
<img srcset="360.jpg 360w,
768.jpg 768w,
1200.jpg 1200w,
1920.jpg 1920w"
sizes="
(max-width: 360px) 100vw,
(max-width: 768px) 90vw,
(max-width: 1980px) 80vw,
768px"
src="360.jpg" alt="">Copy the codeLet’s read the information for the IMG tag one by one
Srcset, we have prepared four quality images for the browser, sizes 360, 768, 1200, 1920. We tell the browser that the width of the image is 100vw when the viewport is less than 360, and 768 when the viewport is less than 768. The image shows a width of 90vw, and so on. The last SRC is introduced as the default image URL, and is a natural fallback to read SRC renderings when the browser does not recognize these attributes.
That’s not intuitive, but let’s do a demo
On iphone4 (320), the image width is the same as we set for 100VW, but why did the browser choose 768 image and not 360 image? Since the DPR of 4 is 2 ^_^, the browser wisely chose the most suitable 768.
And if you look at 6p (414), which is pretty obedient to our setup, it says 90vw. Because of its higher DPR, the browser wisely chose 1200 quality images.
Here we can trick the browser:
360.jpg 1200w,
1200.jpg 9999wCopy the codeWe take the 360 image, trick the browser into saying it’s a 1200, and then we throw the 1200 up in the air
The browser was fooled, he took 360 as 1200 to use. I might be wondering, why isn’t the width of the image 90vw? Because the browser was fooled and didn’t know it, he was still adapting DPR to 1200 images. 414*90%* 360/1200 is approximately 111.7. This is a smart way for the browser to use sizes to select the most appropriate image from the W list. Because it’s so smart, it’s not very controllable in practice, and some of the images that we want to control with precision don’t always work. And it’s a little bit more complicated to deal with when you’re doing lazyLoad.
At this point, consider another approach.
1.2.2. Picture element can be controlled accurately
The picture element is like a container for the image and its source. Browsers still need the IMG element to indicate that images need to be loaded, and without img, nothing will be rendered. Source provides the browser with an alternative version of the image to display.
Applicable scenarios: when a specific breakpoint needs to display a specific image. Using the picture element to select an image, there is no ambiguity and it is more intuitive to understand.
<picture>
<source media="(min-width: 960px)" srcset=960.jpg">
<source media="(min-width: 768px)" srcset="768.jpg">
<img src="360.jpg" alt="">
</picture>Copy the codeIn this case, an image of image 960 is loaded when the ViewPort is greater than 960 pixels. When the viewPort width is greater than 768 pixels, the browser will load 768 pixels. When the width is less than 768 pixels, the default image 360 is loaded.
And lazy loading is very easy to handle, just a slight improvement on the traditional lazyload strategy
Data-src data-srcset is changed to SRC srcset when it is loaded
It’s easy to solve.
Snghr.tencent.com is used a lot
It also doesn’t need to backtrack, just reads the IMG tag when the browser doesn’t support it. For lazy-loading rollback…… I choose to judge IE 7-8… Send him the URL directly to….. .
2. Application and rollback of special format images
Features: Significant volume optimization effect Difficulty: compatibility control
The picture element also provides options based on the picture format.
There are some image formats that guarantee good image quality with smaller file sizes. That sounds great, but the hard truth is that none of the new formats are supported by all browsers. Google’s WebP works well, but only Chrome and Opera soundtracks support it. Jpeg-xr, originally known as HIGH Definition Photos, is a proprietary image format released by Microsoft and supported only by Internet Explorer
<picture>
<source type="image/vnd.ms-photo" src="test.jxr">
<source type="image/jp2" src="test.jp2">
<source type="image/webp" src="test.webp">
<img src="test.png" alt="test">
</picture>Copy the codeThe source type property specifies the MIME type for each image, and the browser selects the first source that contains the MIME type it supports. The order of the sources is critical; if the browser cannot recognize all image types, it will fall back to the original IMG element.
However, most of the current support for these formats will not do this directly, because the code will be a bit redundant and ugly, some determine the browser UA output different DOM or style, and some directly output server side. Direct output by the server or special processing by CDN to switch the format without perception, while reserving URL and rejected interface, which is more flexible and saves time and effort. For example, our:
The server returns different image formats based on the browser’s request header. SharpP is also supported by the X5 kernel.
3. The SVG applications
Difficulty: color-changing scheme, responsive positioning calculation
The source type attribute above also supports another image format that is more commonly used, SVG.
Speaking of SVG, an image format that appears more frequently than WebP, it has more advantages than IconFONT, so it is now widely used on the Web.
Advantages:
1.SVG provides a feature set that includes the ability to nest transformations, clipping paths, Alpha channels, filter effects, etc. It also has vector capabilities that traditional images do not have, and can be adapted to any HD screen.
2. Good readability, conducive to SEO and barrier-free
Compared with iconfont
1. Different rendering methods
As for the rendering method, Owen’s previous article has been very clear, and there is no more narration here (isux.tencent.com/svg-icon-pa…) In black and white, gray, sub-pixel, Or DirectWrite or GDI renderings, iconFont is a font, and it is hard to avoid jagged renderings, especially under double screen.
2. Icon font supports only monochrome
As a font, icon font cannot support multi-color graphics, which causes many limitations to the design, so it also becomes a bottleneck of Icon font.
3. Icon font is not readable
Icon font mainly uses Unicode symbols to call corresponding ICONS on a page, which is not as good for browsers, search engines, or accessibility as SVG
Before finishing the comparison, some students may ask, SVG and iconFONT comparison has a fatal disadvantage, is the color change.
For example, hover color change, iconfont as long as write a color is good, SVG does not need to do two colors of the graph? This is also one of the difficulties we solve with SVG image applications
SVG color swap, I initially tried three schemes
The first is mask-image attribute. Its advantage is simple and crude. It directly uses CSS to mask the SVG image for color change, but its disadvantage is obvious compatibility.
The demo:
background: #ff6600;
-webkit-mask:center no-repeat;
-webkit-mask-image: url(qq-logo.svg);Copy the codeTo view the demo
The other is to achieve through SVG filter, the advantage is better effect, disadvantage in addition to compatibility, but also need additional script coordination. The detailed description of the filter color change is described in detail in my last article and demo
To view the article
Thirdly, we finally chose the bottom-level sensorless color changing scheme, integrating the script to modify the color into our workflow. When we write CSS, we only need to change the color of SVG
background-image: url(test.svg? fill=#ffffff)Copy the codeAdd a color change parameter, and the workflow will automatically generate the SVG image you need at the bottom and merge it into Sprite.
Another difficulty in SVG application is the calculation of background-position and background-size of Sprite image as a responsive rendering of background image. In fact, this is also a difficulty for other images.
My tutor Wenju posted about this calculation formula earlier:
The percentage value () is the percentage of the background image relative to the background positioning area, which can be controlled to display only part of the Sprites image in the container element. For example, in the figure below, the Sprites diagram is composed of four images. To display only the first image in the container, what should be the value of background-size?
We only need 1/4 of the Sprites diagram to be displayed in the container, so the ratio of the Sprites diagram to the container should be 4:1, and the calculation formula is: background size: ( Sprites width / image width) (Sprites height / image height)
How do I calculate background-position
Here’s what we know:
ImgPosX, imgPosY. SpritesW * spritesH. SpritesW * spritesH
We assume:
The distance between the (x, y) point on the container and the upper left corner of the container is cX, and the distance between the (x, y) point on the cY Sprites diagram and the upper left corner of the picture is sX, sY
If we want to display an image completely within a container element, we can derive:
elW = imgW, elH = imgH
cX = sX, cY = sY
Based on the above information, I can calculate the specific value of (x, y), using x% as an example:
cX = elW * x
sX = spritesW * x – imgPosX
elW * x = spritesW * x – imgPosX
After solving the equation, you get the calculation formula:
x = imgPosX / (spritesW – elW) = imgPosX / (spritesW – imgW)
y = imgPosY / (spritesH – elH) = imgPosY / (spritesH – imgH)
Would you be exhausted if you did it manually every time? So we integrated this step into the workflow and used this formula to automatically calculate the position of all the places where Sprite images were merged.
The rollback of SVG has been a platitude
Such as
<svg width="200" height="200">
<image xlink:href="svg.svg" src="svg.png" width="200" height="200" />
</svg>Copy the codeSVG tags, disadvantages must be specified width and height, there is no image to maintain the height of the feature, advantages of good compatibility, compatible with all mainstream browsers
or
<picture>
<source type="image/svg+xml" srcset="svg.svg">
<img src="svg.png" alt="">
</picture>Copy the codeSVG can be used in supported browsers and PNG can be displayed in unsupported browsers. The advantage is that type is flexible and can be used in SVG and WEBP, etc. Besides, img tags are maintained to facilitate layout operations. Disadvantages: high compatibility requirements, ios9+, android 5+, Microsoft Edge+ of course, this compatibility refers to source type compatibility, not SVG compatibility itself.
The application and rollback strategy of SVG in CSS is relatively simple and mature, which is generally used in this way
background-image: url(fallback.png);
background-image: url(image.svg), none;Copy the codeThe technology used is CSS3 multi-background, and browsers that support multi-background almost invariably support SVG
or
background-image: url(fallback.png);
background-image: image-set( "test.png" 1x, "test-2x.png" 2x,
"test-print.png" 600dpi );Copy the codeFilter and rollback through image-set.
This paper introduces some small knowledge points related to the adaptive application strategy of responsive images, the principle of backtracking, the color changing skills of SVG, the calculation formula of percentage positioning of Sprite diagram, etc., in order to help some students quickly clarify the idea of image application, as well as some application skills of Web images.
1. Application and rollback of responsive images
Features: simple application, easy to use, good performance Difficulty: LazyLoad implementation
According to the responsive images used by different devices, different resolutions and different pixel ratios, there are two commonly used scenarios:
1.1 Fixed size image
Based on device pixel ratio selection, many website logos are an example of fixed-width images that remain the same width regardless of viewPort width.
The following is an example of how images in dom and CSS are written
<img srcset="test.jpg 1.5x, test2.jpg 2x" SRC ="test.jpg" Alt ="" />Copy the codebackground-image: image-set(url(test.jpg) 1x,url(test2.jpg) 2x);Copy the code1.2 Image without fixed size
There are two common ways to handle content-related images, which are not always the same size when they need to be responsive and change with the viewport
1.2.1 We use srcset with w descriptor and sizes attribute.
The W descriptor tells the browser the quality of each image in the list. The sizes property is a comma-separated list of two values. According to the latest specification, if any image in the SRCset uses the W descriptor, then the sizes property must be set.
The sizes property has two values: the first is a media condition; The second is the source image size value, which determines the width of the image under certain media conditions.
Such as:
<img srcset="360.jpg 360w,
768.jpg 768w,
1200.jpg 1200w,
1920.jpg 1920w"
sizes="
(max-width: 360px) 100vw,
(max-width: 768px) 90vw,
(max-width: 1980px) 80vw,
768px"
src="360.jpg" alt="">Copy the codeLet’s read the information for the IMG tag one by one
Srcset, we have prepared four quality images for the browser, sizes 360, 768, 1200, 1920. We tell the browser that the width of the image is 100vw when the viewport is less than 360, and 768 when the viewport is less than 768. The image shows a width of 90vw, and so on. The last SRC is introduced as the default image URL, and is a natural fallback to read SRC renderings when the browser does not recognize these attributes.
That’s not intuitive, but let’s do a demo
On iphone4 (320), the image width is the same as we set for 100VW, but why did the browser choose 768 image and not 360 image? Since the DPR of 4 is 2 ^_^, the browser wisely chose the most suitable 768.
And if you look at 6p (414), which is pretty obedient to our setup, it says 90vw. Because of its higher DPR, the browser wisely chose 1200 quality images.
Here we can trick the browser:
360.jpg 1200w,
1200.jpg 9999wCopy the codeWe take the 360 image, trick the browser into saying it’s a 1200, and then we throw the 1200 up in the air
The browser was fooled, he took 360 as 1200 to use. I might be wondering, why isn’t the width of the image 90vw? Because the browser was fooled and didn’t know it, he was still adapting DPR to 1200 images. 414*90%* 360/1200 is approximately 111.7. This is a smart way for the browser to use sizes to select the most appropriate image from the W list. Because it’s so smart, it’s not very controllable in practice, and some of the images that we want to control with precision don’t always work. And it’s a little bit more complicated to deal with when you’re doing lazyLoad.
At this point, consider another approach.
1.2.2. Picture element can be controlled accurately
The picture element is like a container for the image and its source. Browsers still need the IMG element to indicate that images need to be loaded, and without img, nothing will be rendered. Source provides the browser with an alternative version of the image to display.
Applicable scenarios: when a specific breakpoint needs to display a specific image. Using the picture element to select an image, there is no ambiguity and it is more intuitive to understand.
<picture>
<source media="(min-width: 960px)" srcset=960.jpg">
<source media="(min-width: 768px)" srcset="768.jpg">
<img src="360.jpg" alt="">
</picture>Copy the codeIn this case, an image of image 960 is loaded when the ViewPort is greater than 960 pixels. When the viewPort width is greater than 768 pixels, the browser will load 768 pixels. When the width is less than 768 pixels, the default image 360 is loaded.
And lazy loading is very easy to handle, just a slight improvement on the traditional lazyload strategy
Data-src data-srcset is changed to SRC srcset when it is loaded
It’s easy to solve.
Snghr.tencent.com is used a lot
It also doesn’t need to backtrack, just reads the IMG tag when the browser doesn’t support it. For lazy-loading rollback…… I choose to judge IE 7-8… Send him the URL directly to….. .
2. Application and rollback of special format images
Features: Significant volume optimization effect Difficulty: compatibility control
The picture element also provides options based on the picture format.
There are some image formats that guarantee good image quality with smaller file sizes. That sounds great, but the hard truth is that none of the new formats are supported by all browsers. Google’s WebP works well, but only Chrome and Opera soundtracks support it. Jpeg-xr, originally known as HIGH Definition Photos, is a proprietary image format released by Microsoft and supported only by Internet Explorer
<picture>
<source type="image/vnd.ms-photo" src="test.jxr">
<source type="image/jp2" src="test.jp2">
<source type="image/webp" src="test.webp">
<img src="test.png" alt="test">
</picture>Copy the codeThe source type property specifies the MIME type for each image, and the browser selects the first source that contains the MIME type it supports. The order of the sources is critical; if the browser cannot recognize all image types, it will fall back to the original IMG element.
However, most of the current support for these formats will not do this directly, because the code will be a bit redundant and ugly, some determine the browser UA output different DOM or style, and some directly output server side. Direct output by the server or special processing by CDN to switch the format without perception, while reserving URL and rejected interface, which is more flexible and saves time and effort. For example, our:
The server returns different image formats based on the browser’s request header. SharpP is also supported by the X5 kernel.
3. The SVG applications
Difficulty: color-changing scheme, responsive positioning calculation
The source type attribute above also supports another image format that is more commonly used, SVG.
Speaking of SVG, an image format that appears more frequently than WebP, it has more advantages than IconFONT, so it is now widely used on the Web.
Advantages:
1.SVG provides a feature set that includes the ability to nest transformations, clipping paths, Alpha channels, filter effects, etc. It also has vector capabilities that traditional images do not have, and can be adapted to any HD screen.
2. Good readability, conducive to SEO and barrier-free
Compared with iconfont
1. Different rendering methods
As for the rendering method, Owen’s previous article has been very clear, and there is no more narration here (isux.tencent.com/svg-icon-pa…) In black and white, gray, sub-pixel, Or DirectWrite or GDI renderings, iconFont is a font, and it is hard to avoid jagged renderings, especially under double screen.
2. Icon font supports only monochrome
As a font, icon font cannot support multi-color graphics, which causes many limitations to the design, so it also becomes a bottleneck of Icon font.
3. Icon font is not readable
Icon font mainly uses Unicode symbols to call corresponding ICONS on a page, which is not as good for browsers, search engines, or accessibility as SVG
Before finishing the comparison, some students may ask, SVG and iconFONT comparison has a fatal disadvantage, is the color change.
For example, hover color change, iconfont as long as write a color is good, SVG does not need to do two colors of the graph? This is also one of the difficulties we solve with SVG image applications
SVG color swap, I initially tried three schemes
The first is mask-image attribute. Its advantage is simple and crude. It directly uses CSS to mask the SVG image for color change, but its disadvantage is obvious compatibility.
The demo:
background: #ff6600;
-webkit-mask:center no-repeat;
-webkit-mask-image: url(qq-logo.svg);Copy the codeTo view the demo
The other is to achieve through SVG filter, the advantage is better effect, disadvantage in addition to compatibility, but also need additional script coordination. The detailed description of the filter color change is described in detail in my last article and demo
To view the article
Thirdly, we finally chose the bottom-level sensorless color changing scheme, integrating the script to modify the color into our workflow. When we write CSS, we only need to change the color of SVG
background-image: url(test.svg? fill=#ffffff)Copy the codeAdd a color change parameter, and the workflow will automatically generate the SVG image you need at the bottom and merge it into Sprite.
Another difficulty in SVG application is the calculation of background-position and background-size of Sprite image as a responsive rendering of background image. In fact, this is also a difficulty for other images.
My tutor Wenju posted about this calculation formula earlier:
The percentage value () is the percentage of the background image relative to the background positioning area, which can be controlled to display only part of the Sprites image in the container element. For example, in the figure below, the Sprites diagram is composed of four images. To display only the first image in the container, what should be the value of background-size?
We only need 1/4 of the Sprites diagram to be displayed in the container, so the ratio of the Sprites diagram to the container should be 4:1, and the calculation formula is: background size: ( Sprites width / image width) (Sprites height / image height)
How do I calculate background-position
Here’s what we know:
ImgPosX, imgPosY. SpritesW * spritesH. SpritesW * spritesH
We assume:
The distance between the (x, y) point on the container and the upper left corner of the container is cX, and the distance between the (x, y) point on the cY Sprites diagram and the upper left corner of the picture is sX, sY
If we want to display an image completely within a container element, we can derive:
elW = imgW, elH = imgH
cX = sX, cY = sY
Based on the above information, I can calculate the specific value of (x, y), using x% as an example:
cX = elW * x
sX = spritesW * x – imgPosX
elW * x = spritesW * x – imgPosX
After solving the equation, you get the calculation formula:
x = imgPosX / (spritesW – elW) = imgPosX / (spritesW – imgW)
y = imgPosY / (spritesH – elH) = imgPosY / (spritesH – imgH)
Would you be exhausted if you did it manually every time? So we integrated this step into the workflow and used this formula to automatically calculate the position of all the places where Sprite images were merged.
The rollback of SVG has been a platitude
Such as
<svg width="200" height="200">
<image xlink:href="svg.svg" src="svg.png" width="200" height="200" />
</svg>Copy the codeSVG tags, disadvantages must be specified width and height, there is no image to maintain the height of the feature, advantages of good compatibility, compatible with all mainstream browsers
or
<picture>
<source type="image/svg+xml" srcset="svg.svg">
<img src="svg.png" alt="">
</picture>Copy the codeSVG can be used in supported browsers and PNG can be displayed in unsupported browsers. The advantage is that type is flexible and can be used in SVG and WEBP, etc. Besides, img tags are maintained to facilitate layout operations. Disadvantages: high compatibility requirements, ios9+, android 5+, Microsoft Edge+ of course, this compatibility refers to source type compatibility, not SVG compatibility itself.
The application and rollback strategy of SVG in CSS is relatively simple and mature, which is generally used in this way
background-image: url(fallback.png);
background-image: url(image.svg), none;Copy the codeThe technology used is CSS3 multi-background, and browsers that support multi-background almost invariably support SVG
or
background-image: url(fallback.png);
background-image: image-set( "test.png" 1x, "test-2x.png" 2x,
"test-print.png" 600dpi );Copy the codeFilter and rollback through image-set.