The implementation of responsive layout relies on media queries (Media Queries), and selects the width size of mainstream devices as breakpoints to write additional styles for adaptation, but this will be more troublesome, and it can only be selected in several mainstream device sizes. Perfect fit below.
Even if the adaptation is achieved by rem units, it is necessary to embed a script to dynamically calculate the size of the root element. ·
In recent years, as mobile support for viewport units has become more mature and extensive, we can try a new approach to truly adapt to all device sizes.
Recognize Viewport Units
First, we need to understand what a viewport is.
In the industry, a theory that is highly respected is the explanation of the viewport proposed by Peter-Paul Koch (known as the "PPK god" in the rivers and lakes) - on the desktop side, the viewport refers to the desktop side, which refers to the browser. The visual area; on the mobile side, it is more complicated, and it involves three viewports: Layout Viewport, Visual Viewport, and Ideal Viewport.
The "viewport" in the viewport unit, on the desktop side, undoubtedly refers to the viewable area of the browser; but on the mobile side, it refers to the Layout Viewport among the three Viewports.
"viewport" in viewport units
According to the CSS3 specification , viewport units mainly include the following four:
- vw : 1vw is equal to 1% of the viewport width
- vh : 1vh is equal to 1% of the viewport height
- vmin : select the smallest of vw and vh
- vmax : select the largest of vw and vh
The viewport unit is different from the % unit. The viewport unit is dependent on the size of the viewport and is defined as a percentage of the viewport size; while the % unit is dependent on the ancestor element of the element.
Measured in viewport units, the viewport width is 100vw and the height is 100vh (the left side is for portrait, the right is for landscape)
For example, if the viewport size of a desktop browser is 650px, then 1vw = 650 * 1% = 6.5px (this is a theoretical calculation, if the browser does not support 0.5px, the actual rendering result may be 7px).
compatibility
Its compatibility is shown in the figure below. You can know that it is supported on the mobile terminal ios 8 and above and Android 4.4 and above, and it is also fully supported in the WeChat x5 kernel.
Screenshot from Can I Use
Screenshot from X5 Core - Can I Use
Use viewport units to fit the page
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 far as the mainstream responsive layout and flexible layout are concerned, the layout implemented by Media Queries needs to configure multiple responsive breakpoints, and the experience it brings is also very unfriendly to users: the layout is at a resolution within the range of responsive breakpoints. It remains the same, and at the moment of responding to the switch of the breakpoint, the layout brings about the switching change of the fault, like a cassette record player "click" again and again.
However, through the elastic layout of dynamic calculation using the rem unit, it is necessary to embed a script in the header to monitor the change of resolution to dynamically change the font size of the root element, so that CSS and JS are coupled together.
Is there a way to solve such a problem?
The answer is yes, by using the viewport unit to realize the adaptive page, it can not only solve the problem of responsive fault, but also solve the problem of script dependence.
Practice 1: Use only vw as the CSS unit
Under this practice of using only the vw unit as the only CSS unit applied, we adhere to:
1. For the size of the design draft to be converted into vw units, we use the Sass function to compile
//iPhone 6 size as the design draft benchmark
$vm_base: 375;
@function vw($px) {
@return ($px / 375) * 100vw;
}
2. Whether it is text or layout height, width, spacing, etc., use vw as the CSS unit
.mod_nav {
background-color: #fff;
&_list {
display: flex;
padding: vm(15) vm(10) vm(10); // padding
&_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 The physical pixel line (that is, 1px on a normal screen and 0.5px on a high-definition screen) is implemented using the transform attribute scale.
//code from http://caibaojian.com/vw-vh.html
.mod_grid {
position: relative;
&::after {
// Implement the bottom 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 images that need to maintain the aspect ratio, padding-top should be used instead
.mod_banner {
position: relative;
padding-top: percentage(100/700); // 使用padding-top
height: 0;
overflow: hidden;
img {
width: 100%;
height: auto;
position: absolute;
left: 0;
top: 0;
}
}
From this, we can realize the page effect of a common layout as follows:
experience address click here
Practice 2: With vw and rem, the layout is more optimized
Although such a page seems to fit well, you will find that because it is a layout implemented with viewport units, it automatically scales depending on the size of the viewport. Whether the viewport is too large or too small, it also scales with the viewport. The mouth is too large or too small, and the limitation of the maximum and minimum widths is lost.
Of course, you don't care about such a small unfriendly user experience, but let's try to fix such a small flaw.
So, I think it is better to combine the rem unit to realize the layout? The core of rem elastic layout is to dynamically change the size of the root element, then we can pass:
- Set the root element size in vw units that change with the viewport, so that it can dynamically change its size.
- Limit the maximum and minimum font size of the root element, with the body plus the maximum width and minimum width
This way we are able to implement maximum and minimum constraints on the width of the layout. Therefore, according to the above conditions, we can conclude that the code implementation is as follows:
// rem unit conversion: 75px is just for convenience, 750px-75px, 640-64px, 1080px-108px, and so on
$vm_fontsize: 75; // Root element size benchmark for iPhone 6 size
@function rem($px) {
@return ($px / $vm_fontsize ) * 1rem;
}
// root element size in vw units
$vm_design: 750;
html {
font-size: ($vm_fontsize / ($vm_design / 2)) * 100vw;
// At the same time, limit the maximum and minimum values of the root element 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 limits to avoid the block element with the default 100% width following the body and being too large or too small
body {
max-width: 540px;
min-width: 320px;
}
No screenshots are given here, but you can click here to experience it online.
summary
Compared with the first method, I personally prefer the second method, for the following two reasons:
First, in practice 2, the user's visual experience is relatively better, and the maximum and minimum width restrictions are increased;
Second, and more importantly, if the mainstream rem flexible layout method is chosen as the page adaptation method for project development, then the second approach is more suitable for later projects to transition from rem units to vw units. Just by changing the calculation method of the size of the root element, you can seamlessly transition to another CSS unit without any other processing, not to mention the use of the vw unit will inevitably become a better adaptation method. It's just not widely used because of compatibility support.
Source: Front-End Development Blog