Large Front End Learning notes finishing "five" REM and PX Conversion calculation method

Objective

This time in the small project is really the use of REM to move the page layout, the project is over I reflect on the previous use of REM ... It turns out that I used to be completely funny about REM usage!! Combined with this small project, I think it's also necessary for me to summarize the REM layout and usage.

PS. Writing may not be very good ...

1. What is REM

The explanation for the Isux team from the Goose Factory is as follows: REM (font size of the root element) refers to the unit of font size relative to the root element. Simply put, it is a relative unit. See REM Everyone will think of EM units, EM (font size of the element) is the unit relative to the font size of the parent element. They are very similar, except that a calculated rule is dependent on the root element one is dependent on the parent element calculation.

So here's a summary, the so-called root element to calculate the way, is to give HTML elements a font-size, and then all of our REM based on this font-size to calculate

For example:

html{font-size:16px;}

Then our 1rem here should be calculated as follows: 1x16=16px=1rem; the browser defaults to 16px may cause the REM computation of trouble and many decimal places, so we can also do this way to initialize the root element:

html{   font-size=62.5%//This is 10/16x100%=62.5% is the default 10px font size}

After this initialization, we are going to have a lot less hassle when it comes to REM computing.

2. Setting viewport mates for zooming

Usually in the writing of the mobile page, we will set viewport to ensure that the page scaling is not a problem, the most common viewport meta tags are as follows:

<meta name= "viewport" content= "Width=device-width, initial-scale=1.0, maximum-scale=1.0, User-scalable=no"/>

The parameters of this label will not be explained in detail, if you need to understand the detailed parameter analysis and interpretation, you can refer to my blog:http://www.cnblogs.com/azhai-biubiubiu/p/5305022.html

As for why to join viewport, I think it is because there are so many different kinds of different brand different brands of mobile phones, but their ideal viewport width summed up is no more than 320, 360, 414, and so on, are very close, The close proximity of the ideal width also means that the site we make for the ideal viewport of a device does not perform as much or even as it does on other devices.

3. How to calculate the Font-size value required for root elements at different resolutions

About this point, there are actually two solutions, one is based on CSS, and the other is to be obtained by JS Computing

A. CSS-based

Generally we do the page, there will certainly be a design, mobile page, in general, the UI out of the map will be fixed width of 640px, which is the standard size of the mobile side; However, we can not rule out that there may be other special circumstances may need to do other sizes of design drawings. So, we can set a benchmark and then look at a table of ISUX teams:

　　　　　　　　　　　　　　　　　　　　　　　　　　

Through the table, we can clearly see how the various resolutions of the calculation, for example: 320 under the font-size of the HTML should be 320/640=0.5 so, when the base of the Font-size 640 is 20px, we should give 320 is defined as 10px;

How do you define it based on a different resolution? Needless to say, the first thought must be media queries. When we do screen adaptation based on media queries, the first thing to consider is the need to do those screens, after all, the various types of mobile phones are dazzling, the resolution is also diverse, here I do a simple example, I have in the past projects involving common screen resolution of media queries:

@media only screen and (min-device-width:320px) and (-webkit-min-device-pixel-ratio:2) {   //For iphone 4, 5c,5s, all IPhO Ne6 magnification mode, individual IPhone6 standard mode
html{
font-size:10px;
}} @media only screen and (min-device-width:375px) and (-webkit-min-device-pixel-ratio:2) {//Standard mode for most IPhone6
html{
font-size:12px;
}}  @media only screen and (min-device-width:375px) and (-webkit-min-device-pixel-ratio:3) {//magnification mode for all iphone6+
html{
font-size:16px;
}  } @media only screens and (min-device-width:412px) and (-webkit-min-device-pixel-ratio:3) {//For all iphone6+ standard modes, 414px Write 412px is due to Samsung Nexus 6 412px, can be processed together
html{
font-size:20px;
}}

The above for the current stage of the common iphone series of media queries, for Android, I found that as long as the 6p+ and 6, basically on the main Android models on the performance will be very good. However, given that some other projects may be backward compatible with the lower version of the situation, I will provide several media query examples, but the specific values, I think we may need to calculate their own.

@media only screen and (-webkit-device-pixel-ratio:.75) {/* Low resolution small size picture style */} @media only screen and (- WEBKIT-DEVICE-PIXEL-RATIO:1) {/* Normal resolution normal size picture style */} @media only screen and (-webkit-device-pixel-ratio:1.5) {/* High-resolution, large-size picture style */}

B. Screen resolution calculation based on JS

Let's take a look at this JS:

(Function (doc, win) {    var docel = doc.documentelement,        resizeevt = ' orientationchange ' in window? ' Orientationchange ': ' Resize ',        recalc = function () {            var clientwidth = docel.clientwidth;
Window.innerwidth>max? Window.innerWidth:max;            if (!clientwidth) return;            docEl.style.fontSize = * (clientwidth/320) + ' px ';        };    if (!doc.addeventlistener) return;    Win.addeventlistener (Resizeevt, Recalc, false);    Doc.addeventlistener (' domcontentloaded ', Recalc, False);}) (document, window);

In fact, a little awkward problem is ... The detailed role of this code I do not fully understand, but through some of the key words, I first do a rough analysis:

Orientationchange: This is an event, as explained in the Rookie tutorial: events are events that are triggered when a user horizontally or vertically flips a device (that is, the direction changes).

The following comprehension, may not be very accurate!! Just to make myself understand what a thing! You mustn't be taken to the pits! Also hope that the great God at the bottom of the analysis of this piece of code!

In fact, this code, the main role is to listen, the core of the code is such a sentence:

DocEl.style.fontSize = (clientwidth/320) + ' px ';

This sentence determines a few key points: 1. The font-size;2 required to calculate REM based on the root element specifies the reference size of the design drawing and the font-size of the Datum. Therefore, in the need to use this JS, we only need to according to the UI design diagram, set a good benchmark Font-size and a unified UI design size is good.

Based on this JS, we also take advantage of this approach in the project processing, but the difference is not using JS, but based on the method of the pre-defined datum, in less to calculate the size can be adaptive

HTML font-size:20-40//corresponds to the screen width 320-640//the current design is 750, we use the width of the design draft 100% to measure more convenient,//So the base conversion @base: (640/750)/40rem;// REM is the unit that finally calculates the result

Then take a look at the following example:

. tag {  display:inline-block;  font-size:22* @base;  Text-align:center;  border-radius:20px;  margin-bottom:20* @base;  padding:10* @base 20* @base;}

The @base in the example is pre-compiled, the benchmark variable that can be computed, and then the size change in the example, I'm multiplying the value from the measured value in the PSD of the UI by the Datum. This can be a bit of a hassle, but the advantage is that the degree of restore to the UI can be particularly high, with the basic ability to do pixel-level UI restores, let's look at the effect:

It can be seen that in Chrome's mobile simulator, the layout has not changed in the resolution of large, medium and small three, but only the content is changed. In the mobile code, we generally only define the width of the element, so that its height adaptive, but in the form of this variable, height can also be defined, so that our CSS more rigorous.

4. The difference between the flow layout and the REM layout

Under Streaming layout:

The main structure of the Web page according to the percentage layout, width percentage, height of death;

If the width of the picture is set as a percentage, the height according to the proportion of the picture adaptive, if the cover picture can be highly dead, with Background-size:cover display part of the line;

In the REM layout, which has been said a lot before, here is the difference between the flow-style layout:

The REM layout needs to be based on the base of the root element, with different screen resolutions setting the baseline amount, the UI will be very high, but ... A REM problem was found ... That is, if the page design is more important than the element spacing and height ... Then the REM layout would be uncomfortable.

5. Summarize the following

In fact, in the actual project, it is more convenient to feel the use of REM, and the cost of learning is not high. If a classmate encounters a mobile project and does not need to consider the PC side, REM will definitely make the CSS more comfortable to write.

Learning, the above is my rem some summary and collation, I hope to see this blog to help people, but also hope to have the great God in the comments point out my shortcomings.

End of the flower ~

Large Front End Learning notes finishing "five" REM and PX Conversion calculation method