Mobile-side adaptation issues

One, the unit
Speaking of mobile terminals, have to mention the problem of adaptation, large and small mobile devices not only make Android and iOS development sad, and now also let the front end is a headache, but the method is always more than the problem,
Because today's mobile devices in the market resolution of different sizes, it is obvious that we commonly used PX units at this time some of the less brilliant, for this, CSS3 out a new unit--rem,rem is relative to the root element

(REM is different from em: REM is the size of the HTML that refers to the root element, and EM is the emmmmmm of the parent element of the current element.) A lot of people can't figure it out)
　

In this way, a wide 50px box will appear, very simple! Found no, some like the em we used to use, but REM is relative to the root element (HTML) font size, Em relative to the parent element's font size.
Although very simple, but mobile devices so much, how can we according to the phone screen resolution, to set the There are 2 ways I know:
1) querying via CSS Media

　　

, through the media query, only need to consider the usual screen width in order to meet most of the application scenarios, but this approach is not rigorous.
2) through JS calculation

, when the page is loaded, JS obtains the device's screen resolution, can calculate the corresponding font size (that place is not necessarily 10, but 10 good calculation),
This method can be adapted to the size of all screens, which is a lot more perfect.
But sometimes it will be very troublesome, because REM will involve conversion problems, such as 70px width, the root directory font is 12px, the conversion formula is: 70/12 = 5.83333333~, each write a unit to calculate with a calculator, then tears, but as a program ape, How can people do this kind of thing, the work can let less or sass and other pre-processor to complete.

Ii. use of viewport in <meta> tags
Do Web mobile development, you think that with REM is perfect? To young too simple, but also to use the META tag in the viewport definition screen, with this thing, hemp no longer have to worry about my mobile adapter problem, talk not much, direct

With this <meta> tag help, the page is almost sorta.

Three, flexible layout box layout
Previous PC-side layouts typically use float, margin, padding, and so on, which not only have tedious calculations, but are also prone to errors on the mobile side. Now mobile, there is a better choice to use the Flex layout method.
Give me a chestnut: use Flex to tab.
HTML:

CSS:

Do the Flexbox the most common function, the implementation of the principle is very simple, only need to "parent element", "sub-elements" respectively given "Display:flex", "Flex:1″ can be." The width of the child element does not change depending on the length of the content. The front-end students to add or subtract the tab number, only need to increase or decrease the DOM structure, no style changes. (Flex-Fit for mobile!!!!!!)
has always been the layout of the problem of compatibility, so that the front-end students want to use, and do not dare to use, the reason is that it is not clear its various versions of the code and compatibility. Surprisingly, at present, in addition to opera Mobile12, the mobile browser is very good to support the flexbox of the old version of the syntax, but does not include the Wrap property of Flex. So you can use it boldly without worrying too much.

Iv. Pits
Layout problem is solved, although now seems to be perfect, however, there are many pits need to guard against.
1. What should I pay attention to when using REM?
A) The effect is somewhat biased.
Why does this happen? It was later discovered that this was due to the different processing of decimal numbers by the browser. When a different browser calculates REM conversion to PX value, the processing of the numeric value after the decimal point is biased, and the source of the REM calculation bias is the difference between the number types of the browser kernel, and if the browser's kernel number type is float, it is better to support numeric values with decimal points. When the browser kernel number type is int type, the decimal point is not supported and the number is rounded, so there is a bias. The larger the element, the more obvious the deviation! This pit is almost unavoidable, and only allows him to better adapt to the most browsers. such as the Chroem kernel.
b) Sprite map positioning problem
From the above we can be informed that the conversion of REM to PX size is not strictly accurate, if the distance between the sprite icon is too small, it may lead to the icon over the bounds, so the gap between the figure and the figure needs to stay a bit larger.
C) REM units used in Google Chrome to note that Google set the minimum font to 12px, if less than 12 he will default display 12px;
Give me a chestnut:
Code:

Look at the code, you should guess, this should be two exactly the same box is right, but the effect is:
PC Effects:

Firefox effect

From the effect, Google big Guy also has temper (if your fontsize less than 12px to pay attention to Google's problems, he can only show to 12, less than 12 or 12 processing)).
2, the use of flexible box models need to pay attention to the problem.
A) Although the mobile side of the major browsers are supported by the old version of Flexbox syntax, but still have to have a compatibility notation;
　

V. Summary
Speaking of this, the Web mobile development in the long-run problem is basically solved, but, learning these are not enough, want to do a good job of web mobile development, or need to learn a lot of things (such as performance, gup acceleration, technology selection, etc.) to make the user Experience Super Good Web page, and, REM is also not a panacea, and there are some scenarios that are not suitable for REM, such as when used as a picture or some non-scalable display, you must use a fixed px value, because scaling may cause image compression and distortion.

Mobile-side adaptation issues