preface
The last legal holiday of 2018 has come to an end. I believe that most of the students who are engaged in or have ever engaged in mobile terminal page development are more or less familiar with the scheme of using REM for mobile terminal page adaptation and vw. (For those who have not known it, please refer to the two articles of Teacher Da Mo to implement terminal adaptation of MOBILE H5 page and talk about the adaptation of mobile page.) I have also been faced with the consideration of choosing between different adaptation schemes. Recently, I have conducted a round of re-research on mobile adaptation schemes. I also have some of my own opinions on various adaptation schemes, which I can record and share with you.
Some thoughts on VW and REM scheme
So, mobile adaptation = VW or REM?
Of course not. Not all situations are suitable for the mobile terminal of the page with vw or rem solution, such solution is the nature of the proportion of the scaling, such as layout for the page under the different size of screen is similar to the vector images scaling effect, which ensure the page position size proportion relationship between the elements, and allow the elements can be shown clearly. Such a scheme is more suitable for mobile pages with a large variety of visual components and strong dependence of visual design on the relative position of elements. Actually most page can use rem or vw scheme ADAPTS, but for the text content is more, or hope to guide users immersed browse pages, I personally don’t recommend using geometric scaling scheme, do not recommend using geometric scaling scheme completely, at least for text content should be directly using the px unit, the absolute length After all, on a larger phone, users expect more content, not bigger. In fact, many of these sites are also directly using PX combined with Flex layout for mobile adaptation, which will be discussed later in the specific technical solutions when I will cite a few examples.
What exactly is the REM scheme doing?
In the implementation of various REM adaptation schemes, there are two core points
- Set up the
<meta name="viewport" content="xxx">
(You can scale the viewport according to DPR, or you can directly use 1 times the viewport size) - The font size of the HTML element is set according to the width of the current layout (usually the viewPort width, or the maximum/minimum layout width that is restricted)
As I have mentioned before, the essence of vw and REM schemes is “equal scale scaling”, because VW and REM are both relative length units, which can well meet this requirement. The difference is that VW is 1% of the viewport width, while REM is the font size of the HTML element. After associating the font size of the HTML element with the viewport width, REM can simulate a VW layout. So in the REM scenario, we’re just thinking of REM as a shadow of VW. Write REM, read vw… (The plot seems to be getting hot… Rem: Choose to forgive you, of course)
Why don’t we just use a VW and get it over with?
caniuse
caniuse
I think someone is going to say, “Wake up brother, it’s 8102 years!” Yes, the year 8102 is almost over, and VW can see the light of day when compatibility requirements are not particularly high, and there are some patches for VW, but there is another problem we need to discuss a little bit…
Can VW completely replace REM?
The answer is still no. Vw alone does not limit the width of the layout, and at least vw and REM should be mixed to deal with boundary cases in scenarios requiring this. This scenario is also described in more detail below, so click the button here.
A summary of mobile adaptation solutions in existing production environments
When we are struggling to find their own path, might as well look up to see how others do. So what are the real world adaptations of Internet companies’ mobile pages? Do you have some special skills? Here are some examples of the CSS length units that are actually used on a page.
The px project
As mentioned in the first paragraph, it is not necessary to use relative length units on mobile devices. Traditional responsive layouts are still a good choice, especially in news, community and other readable scenes, where using px units directly can create a better experience. The PX scheme allows larger screen phones to display more content, which is more in line with people’s reading habits. Some of the sites using this scheme are:
-
tencent
The home page of mobile terminal is mainly news content, which needs better reading experience. It is suitable to use PX directly for layout.
-
zhihu
Zhihu is also a typical scene in pursuit of reading experience. Unsurprisingly, px is directly used.
-
review
Rich visual elements, still using THE PX scheme, the page is basically flex layout, very good adaptation
-
headlines
The headline solution is a bit special. It still sets the font size of HTML elements, adds the data-dPR attribute and scales the viewport, but the final CSS output is still PX, does not use REM, and defines the styles for different DPR, as shown below:
This will solve the 1px border problem, and the text size will not vary with the screen size (there is a lot of text). Although I can’t find any rem use for this, I can do rem layout for special elements as needed, but this should cause the CSS file size to double. And exporting CSS like this is certainly not without the support of building process plug-ins, which is a specific solution.
The final output of PX can not be a flexible layout like REM/VW.
-
taobao
What? Showed us the article for a long time and it turned out to be PX?
In fact, if you are smart, you will soon find that the adaptation scheme of Taobao mobile terminal and REM/VW scheme are actually similar in effect. The style of elements are generated by JS. Although the unit is px, the scheme is still scaled based on the width of 375px. In principle, it should be a CSS in JS solution, but the rem solution internalizes the process of setting the FONT size of HTML elements into the process of using JS to calculate the style of elements. Such a scheme involves the unity and support of the overall development framework and is not a special general scheme. The advantage may be that using px units directly gives more accurate results. It’s kind of a masterstroke. Of course, Taobao still has a lot of product lines, it is not necessarily the same adaptation scheme (such as the example of the desert teacher article), here only for the mobile home page.
Rem solution
In general, REM schemes are mainly divided into two types. One is the scheme for scaling viewport, such as lib-flexible, which can deal with details like 1px border more easily. However, media Query is affected. The other option is to leave the viewPort unscaled and introduce a separate solution for problems such as 1px boder. There are many different ways to define the base size of an HTML element, fong-size. There is no standard for this, so I’ll just give you a few examples:
Don’t zoom viewport
(The mappings between REM and PX shown below are all for 375px screen width)
-
Hornet’s nest 1rem = 37.5px
-
Xiaomi 1rem = 52.0833px
-
Little red book 1rem = 50px
-
weibo
1rem = 16px indicates that the font size of weibo is generated according to media query
Zoom in the viewport
(The mappings between REM and PX shown below are all in the case of 375px screen width and viewport Scale 0.5)
- Comment 1rem = 100px
- Station B main station 1rem = 46.875px
- Sohu 1rem = 75px
Vw plans
Here it is, at last! So many problems about VW have been mentioned before. Is there any plan to use VW on a large scale for existing products? How does the compatibility scheme work?
-
jingdong
The home page of JINGdong’s mobile terminal adopts vw+ REM layout. Rem units are still used in element layout without zooming viewport. Font size of HTML elements is vw+ PX fallback, and media Query is used to limit layout width, as shown in the figure below
Under normal conditions:
Boundary case
-
netease
Netease’s scheme is basically the same as jingdong’s. It does not zoom the viewport, uses media Query, only handles font size of HTML elements, and limits the layout width.
-
Hungry?
Ele. me also adopts VW + REM scheme, but the viewport is scaled and the layout width is not limited. The font size of HTML elements is still specified by PX, but vw+ PX fallbak is used for the layout of specific elements, as shown below:
It can be seen that using the above two VW + REM schemes will not change the existing REM scheme very much, and both adopt vw+ Fallback, thus ensuring the compatibility problem, but ele. me scheme may need plug-in support in the construction process more (ABOUT this, I will explain to you later what is called surprise). In this way, I personally do not recommend the use of Viewport-Units – BuggyFill library for compatibility in VW scheme proposed by Mr. Da Mo, because the library uses CSS Content attribute for compatibility processing. The official document points out that the IMG tag of some browsers is affected. A CSS rule needs to be imported globally. There are also inevitable conflicts in cases where content needs to be used properly (e.g., icon fonts), and compatibility with pseudo-elements is not supported. So from my personal point of view, if you have to ask me what VW adaptation scheme to use, I would recommend the above two VW + REM schemes to you.
Is that all?
Of course not, I just listed a few typical mobile terminal adaptation schemes, in fact, in the specific implementation details can grasp a lot of points, suitable is the best, that silver bullet may not appear, but we have never lacked sharp tools.
Color (an) egg (Li) part
I believe that most students also have the idea to integrate VW into the existing mobile terminal adaptation scheme in practical development. As for the two VW + REM schemes I mentioned above, the scheme that only changes the FONT size of HTML elements is not very expensive for students who are already using REM schemes, and only needs to change the font size in the original media Query (or when js generates the style) : Font-size: *vw font-size: *vw font-size: *vw
Ele. me’s way of printing REM + VW while using length units is definitely done with a little extra plugin. If you, like me, happen to use Stylus as a CSS preprocessor, I’ve written a plug-in for Stylus to help you with this problem. This plugin allows you to use PX to write CSS in your development process. Unlike some existing plugins, it supports output from multiple adaptation schemes. Currently, it supports output from REM, pure VW and the vw+ REM scheme mentioned earlier. It also makes it easy to handle scenarios where you don’t want to convert PX. That is, if you’re using rem now, you can just use the plugin instead, and when you need to switch to VW or VW + REM, it’s pretty seamless.
For details and examples, see pandaGao/stylus-px-to-relative-unit