Are you still using REM flex? Putting a chunk of compressed JS code in the header of an HTML file makes you feel bad? Learn about VW, which makes your code purer

Briefly introduce the REM layout scheme

Rem is a unit of length in CSS. 1rem is the font size of the HTML of the root element. When all elements on the page use REM units, all you need to do is change the font size of the root element and everything will be scaled up or down. So we just need to write a little JS code and change the FONT size of the HTML according to the width of the screen to achieve an elastic layout. This method is really convenient, compatibility is also very good, is currently very mainstream elastic layout scheme. However, this scheme has its drawbacks. (One drawback is that it is strongly coupled to the font size value of the root element, resulting in layout confusion when the system font is enlarged or shrunk; Drawback # 2: the HTML file header needs to insert a piece of JS code), this article will introduce a better pure solution.

Vw units achieve flexible layout

Vw: 1% of viewport’s width VH: 1% of Viewport’s height

So viewPort is the size of the area that the browser can see and we can think of it as 100VW = window.innerWidth, 100vh = window.innerheight and on mobile we can think of 100VW as the width of the screen. With VW layout, there is no need to dynamically set the font size of the root element in JS, as rem did, and only need to use this function for conversion in SASS

// take iphone7 @2x 750 pixels wide as an example
@function vw($px) {@return ($px / 750) * 100vw;
}

// Assume that a div element is in the visual draft with a width of 120px and a font size of 12px
div {
    width: vw(120);
    font-size: vw(12);
}
Copy the code

Vw versus %

What is the difference between 100VW and width:100%?

1. The percentage % is calculated according to the width or height of the parent element, while VW VH is calculated according to viewport and will not be affected by the width and height of the parent element.

2.100vw includes the width of the page scrollbar (the page scrollbar belongs to the viewport, 100vw of course includes the page scrollbar width). Setting body or HTML to width:100% does not include the width of the scroll bar. So 100vw with a vertical scroll bar is going to be wider than 100%. This leads to a problem: when vw is used on the PC side, if the page content is longer than one screen length and there is a vertical scrollbar with an element width:100vw, then a horizontal scrollbar will appear because the element (100vw + scrollbar width) exceeds the viewPort width. (Mobile scrollbars do not occupy space, so there is no problem with this.)

According to CSS3 specification, viewport units mainly include the following four:

  • Vw: 1VW is equal to 1% of the viewport width
  • Vh: 1vh equals 1% of the viewport height
  • Vmin: Choose the smallest of vw and vH
  • Vmax: Pick the largest of vw and vH

Measured in viewport unit, viewport width is 100VW, height is 100vh (left is portrait screen, right is landscape screen)

For example, if the browser viewport size is 650px on the desktop, 1VW = 650 * 1% = 6.5px (this is a theoretical calculation, if the browser does not support 0.5px, the actual rendering might be 7px).

compatibility

Use palatability units to adapt pages

For mobile terminal development, the most important point is how to adapt the page, to achieve the compatibility of multi-terminal, different adaptation methods have their own strengths, but also have their own shortcomings.

In terms of the mainstream responsive layout and elastic layout, the layout realized by Media Queries needs to configure multiple response breakpoints, and the experience is also very unfriendly to users: the resolution of the layout within the range of response breakpoints remains unchanged, and at the moment of response breakpoints switching, the layout brings a fault switching transformation. Like a record player on a cassette, clicking and clicking.

In the flexible layout with dynamic calculation in REM units, it is necessary to embed a script in the head to monitor the change of resolution to dynamically change the font size of the root element, which makes CSS and JS coupled together.

Is there a way to solve this problem?

The answer is yes, adapting pages by using palatability units solves both reactive faulting and script dependency.

Usage based on iPhone6 (750)

The first step is usually to set the meta tag on the mobile

<meta name="viewport" content="Width =device-width, initial-scale=2.0, maximum-scale=2.0, minimum-scale=2.0, user-scalable=no">
Copy the code

Since the iPhone6 and most DPR are 2, convert for the convenience of step 2

The second step is to set the body and HTML font size

html {
    font-size: 13.3333333333333vw // 100px
}
Copy the code

13.33333333333 VW?

  • The palatability is 100vw, based on iPhone6 750px
  • Combines/iPhone6
    • Vw / 750 = 0.1333333333333 VW
  • If we use 100px as a palatability then
  • 100px / 750 = 0.1333333333333 px
  • So 1px = 0.1333333333333 VW
  • So the whole palatability equals 0.1333333333333 * 10013.33333333333 VW = 100px
  • So 100px is equal to 1rem

And by doing this we’re using VW to convert REM to a base of 100px

It’s good to use it on a project

div {
 
     // width: 100px;
     width: 1rem; 
}
 
span {
   // height: 12px
    height: 12.rem
}
 
Copy the code