Recommend a new mobile multi-screen adaptation solution (H5 + applets)

A proposed scheme

These two years small program development hot, small program recommended use of RPX units, namely: 750 design draft, 1rpx=1px, 750rpx=100vw=100%, the biggest advantage of this scheme is that the size of the design draft mark can be directly used to write CSS, without any tool calculation, developers do not need to consider compatibility issues, are compatible by the small program itself. This gave our team a: why don’t we call the RPX unit or rolled out this idea, so we put forward a solution: use the RPX for the entire front-end development, including small programs, h5, and other, convert the RPX to vw packaging, don’t support the vw do downgrade, developers need to consider the unit conversion.

Here is a brief introduction of our proposed scheme:

Write CSS using RPX, 1rpx=1px (original design unit)
The postSS plugin postCSs-rpx-to-viewPort is recommended to convert RPX to VW when packaging according to the application environment
To determine if your application needs VW degradation, simply introduce vW-Polyfill (or insert it directly into the source code) at the beginning or end of the body tag in your HTML file

Very simple 2-3 steps to get mobile multi-screen adaptation

The code:

.foo {
  width: 750rpx;
  height: 150rpx;
  margin: 10rpx;
  padding: 1px 1rpx 1px 1rpx; /* all rpx will be converted */
  border: 4px solid gray;   /* px will not be converted */
  font-size: 15rpx;
  line-height: 14rpx;
}
Copy the code

.foo { width: 100vw; height: 20vw; Margin: 1.33333 vw; Padding: 6px 0.8vw 6px 0.8vw; /* all rpx will be converted */ border: 4px solid gray; /* px will not be converted */ font-size: 2vw; The line - height: 1.86667 vw; }Copy the code

.foo { width: 100rem; height: 20rem; Margin: 1.33333 rem; Padding: 6px 0.8rem 6px 0.8rem; border: 4px solid gray; The font - size: 2 rem; The line - height: 1.86667 rem; }Copy the code

Writing in the front

This article assumes that you already know some of the necessary knowledge of mobile multi-screen adaptation, such as viewport, REM, VW, DPR, META tags, etc., if you are not familiar with the place, please move: Using Flexible to achieve mobile H5 page terminal adaptation and then talk about mobile page adaptation two articles, it is very good.

Since we got to the mobile end, we have been bothered by the various sizes and densities of mobile phone screens. In order to make the design work relatively consistent on different mobile phone screens, we have tried many schemes. Such as:

Use percentages for layout, px for details (Cons: inaccurate)
Multiple versions of CSS with meta tags for screen case (Cons: too cumbersome)
Use rem units and meta tags to set htmlfont size (drawback: only compatible with several levels of screen size, not fully compatible)
Around the end of 2015, thanks to @Mo.com’s flexible. Js (the first document above), the scheme of dynamically changing htmlfont size by JS to simulate VW has solved the problems we are facing better (of course, there are some problems here, so I won’t expand the details).

Now that VW is supported by most browsers, rem emulation of VW is no longer necessary. Let’s talk about how to use VW for adaptation

Plan advantage

Let’s take a look at some of the benefits of the new scheme:

Why vw instead of REM?
- The rem scheme was originally designed to simulate VW, and now that VW is supported by most browsers, REM is no longer necessary
- Flexible solutions require additional js files to be placed in the head, which has a slight impact on page performance.
- Js dynamic HTML font size change scheme, will trigger the whole page style re-rendering, in some browsers visible delay style change, bad experience.
- Vw units are more intuitive, 1vw is 1% of the page width, which makes sense, rem requires all sorts of conversions…
How compatible is VW?
- Although most browsers already support VW units, there are still a small number of mainstream models that do not support them. Whether to downgrade depends on the model of your product.
- In our actual tests, we found some unsupported devices and browsers, not just the ones shown in the image below, but some of the older versions of Android as well.
  
  Figure 1:caniuse
  
  Figure 2 is from the article:Talk about the adaptation of the mobile page
Why RPX?
- If you are also faced with developing applets and H5 ~ at the same time
- If you’ve ever had a design marked 100px, divide by 2 in your mind before writing it to your CSS file.
- Also write various less/sass functions, hybrid macros? Too much trouble;
- Automatic conversion with a browser plug-in? Rem code is difficult to understand and maintain;
- Automatic conversion with post plug-in? Write a comment after the px to tell the plugin that there is no need for conversion.
- After using RPX, you only need to write RPX where you need to convert, and write PX where you don’t need to, so it doesn’t affect each other. Of course, “RPX” is just a suggestion, you can use something else to distinguish it from “px”
How to easily do downgrade?
- I have investigated several schemes for VW degradation (I am not interested in details and just skip them, see the following solution), including: Viewport Units Buggyfill and Vminpoly, the scheme of Viewport Units Buggyfill is probably used in CSS packaging, combined with the plug-in postCSS-Viewport-units, Add a Content property to all styles that require conversion units, and insert an additional copy of the style content. Viewport Units Buggyfill is initialized when the page is loaded to determine the browser model and determine whether to downgrade according to android and version. This judgment method is not very rigorous. In the actual test, many mobile phones with higher Android versions (such as Android 6) are also not supported by VW. For example, huawei p9, mate9, etc., then get all styles and content through document.styleSheets, insert the alternative styles in the content property into the stylesheet. It’s also a hassle to use, with two plug-ins in the package, another reference in the HTML, and a larger CSS file size because of the added content properties. Vminpoly’s solution feels better, using the method of inserting elements to dynamically determine whether the browser support, and then reload the CSS source code to convert VW to PX, the disadvantage is that when the page width changes, need to convert and render, and VminPoly is a little big, 10KB left.
- Therefore, we made vW-Polyfill degradation scheme, which borrowed some advantages of the above scheme, such as dynamic detection of whether the browser supports VW, but we chose the scheme of directly converting VW into REM, and set the FONT size of HTML. Rem = 1 vw. When the page width changes, you only need to change the HTML font size, and do not need to completely re-convert VW. Since vw units are already supported by most browsers, if you don’t want demotion for a few browsers to affect the page experience of most users (although it’s already very small), you can load them last in the body tag. Sacrifice a user experience that doesn’t support VW browsers.
- Vw-polyfill is less than 100 lines of code and can be easily degraded by importing (or injecting HTML directly is recommended) a JS file without any dependencies or other plug-ins. Ex. :
```
* {
    padding: 0;
    margin: 0;
    box-sizing: border-box;
}
.a {
    width: 25vw;
    height: 25vw;
    background-color: #ff3336;
}
.b {
    width: 50vw;
    height: 50vw;
    background-color: #5f98ff;
}
Copy the code
```
```
<head>
  <meta charset="utf-8"/>
  <title>test vw polyfill</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="stylesheet" href="test.css">
  <style>
    .c {
      width: 100vw;
      height: 100vw;
      background-color: #f8ff38;
    }
  </style>
  <style>
    body {
      background-color: antiquewhite;
    }
  </style>
</head>
<body>
<div class="a">
  test div a
</div>
<div class="b">
  test div B
</div>
<div class="c">
  test div c
</div>
<script src=".. /vw-polyfill.min.js"></script>
</body>
Copy the code
```
Effect:

How to write and pack?
- Assuming our design is 750px and the element A (class A) annotation is 100px, you just write. A {width: 100rpx}
- There are many ways to convert RPX to VW. We recommend using postcss-rpx-to-viewport, which does not need any Settings and is added directly at packaging time. To see how this works in vue and React projects, see Readme.
- It doesn’t matter if your design is not 750, just set the plugin’s {layoutWidth: ‘Your design size ‘}
- In this way, your CSS file still has RPX units, which correspond to the design draft one by one, making it easier to maintain later.
- There are many other ways to convert RPX to VW, such as other postCss plug-ins, editor plug-ins, less/sass functions, mixed macros, etc., you can choose by yourself, but I won’t expand here.

mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.

Recommend a new mobile multi-screen adaptation solution (H5 + applets)

A proposed scheme

Writing in the front

Plan advantage

Other problems

Recommend a new mobile multi-screen adaptation solution (H5 + applets)

A proposed scheme

Writing in the front

Plan advantage

Other problems

Related Posts

The jSON-Schema visual editor is published

Understand Node in comparison

Touching hands takes you into front end unit testing