#Explain
Reference: Wang who studies hard: Hong learning notes
This is what I read by chance[ Real fluid typesetting using VH and VW The insights and achievements of this article are also full of joy and hope that this article can also give readers some inspiration, and put forward some secrets for vw units to communicate ~:) original text: Concave convex Laboratory
Adapting pages with viewport units
For mobile terminal development, the most important point is how to adapt the page to achieve multi terminal compatibility. Different adaptation methods have their own advantages and disadvantages. As for the mainstream responsive layout and elastic layout, the layout realized through Media Queries needs to be configured with multiple response breakpoints, and the experience is also very unfriendly to users: the layout remains unchanged at the resolution within the range of response breakpoints, while at the moment of response breakpoint switching, the layout brings fault switching changes, like a cassette player Floor after floor. For the elastic layout with dynamic calculation in rem unit, a script needs to be embedded in the head to monitor the change of resolution and dynamically change the font size of the root element, so as to couple CSS and JS together. Is there any way to solve such a problem? The answer is yes. By using viewport units to realize adaptive pages, we can not only solve the problem of response fault, but also solve the problem of script dependency.
Practice 1: only use vw as CSS unit
Under the practice of using only vw unit as the only CSS unit for application, we comply with the following: 1. For the size conversion of design draft to vw unit, we use Sass function to compile
//iPhone 6 size as the basis of design draft $vm_base: 375; @function vw($px) { @return ($px / 375) * 100vw; }
2. vw is used as CSS unit for both text and layout height, width and spacing
.mod_nav { background-color: #fff; &_list { display: flex; padding: vm(15) vm(10) vm(10); // Inner spacing &_item { flex: 1; text-align: center; font-size: vm(10); // font size &_logo { display: block; margin: 0 auto; width: vm(40); // width height: vm(40); // height img { display: block; margin: 0 auto; max-width: 100%; } } &_name { margin-top: vm(2); } } } }
3.1 physical pixel lines (i.e. 1px under normal screen and 0.5px under high-definition screen) are implemented by transform attribute scale.
.mod_grid { position: relative; &::after { // Implement the lower border line of 1 Physical pixel content: ''; position: absolute; z-index: 1; pointer-events: none; background-color: #ddd; height: 1px; left: 0; right: 0; top: 0; @media only screen and (-webkit-min-device-pixel-ratio: 2) { -webkit-transform: scaleY(0.5); -webkit-transform-origin: 50% 0%; } } ... }
4. For graphs that need to maintain aspect ratio, padding top should be used instead
.mod_banner { position: relative; padding-top: percentage(100/700); // Using padding top height: 0; overflow: hidden; img { width: 100%; height: auto; position: absolute; left: 0; top: 0; } }
Practice 2: match vw and rem to optimize the layout
Although such a page seems to fit well, you will find that because it uses the layout of viewport units, it automatically scales depending on the viewport size. No matter whether the viewport is too large or too small, it also loses the limit of maximum and minimum width as the viewport is too large or too small. Of course, you can not care about such a small unfriendly user experience, but let's try to repair such a small flaw. So, I think it's better to combine rem units to realize layout? The core of rem elastic layout is to dynamically change the size of the root element, so we can:
- Set the size of the root element to vw units that vary with the viewport, so that its size can be changed dynamically.
- Limit the maximum and minimum font size of the root element, combined with the body plus the maximum width and minimum width
In this way, we can achieve the maximum and minimum limit on the layout width. Therefore, according to the above conditions, we can conclude that the code implementation is as follows:
// rem unit conversion: 75px is just convenient for calculation, 750px-75px, 640-64px, 1080px-108px, and so on $vm_fontsize: 75; // iPhone 6 size root element size base value @function rem($px) { @return ($px / $vm_fontsize ) * 1rem; } // The root element size is in vw units $vm_design: 750; html { font-size: ($vm_fontsize / ($vm_design / 2)) * 100vw; // At the same time, the maximum and minimum values of root elements are limited through Media Queries @media screen and (max-width: 320px) { font-size: 64px; } @media screen and (min-width: 540px) { font-size: 108px; } } // The body also increases the maximum and minimum width limit to prevent the block element with the default 100% width from following the body body { max-width: 540px; min-width: 320px; }
Summary
Compared with practice 1, I prefer practice 2 for the following two reasons: first, practice 2 has a better user visual experience and increases the limit of maximum and minimum width; Second, more importantly, if the mainstream rem flexible layout method is selected as the adaptation page method of project development, then practice 2 is more suitable for the transition from rem unit to vw unit in later projects. Just by changing the calculation method of the root element size, you can seamlessly transition to another CSS unit without any other processing. Moreover, the use of vw unit is bound to become a better adaptation method. At present, it is only not widely used due to the support of compatibility.