Front-end mobile adaptation summary

What do meta tags actually do

Mobile adaptation partners must have encountered this line of code:

<meta name="viewport" content="Width = device - width, initial - scale = 1.0">Copy the code

But a lot of people just assume: oh, I add this line of code and the width of the page will match the width of my device. However, this understanding is very one-sided. So what is the essence of this statement?

Not so fast, but let’s move on to the bottom, and we’ll keep you in suspense.

Several proper nouns and units

Here, we first discrimination in the adaptation of the time often encountered some nouns, numerical units.

First, take a look at the physical pixels.

Take iphone6 as an example, can know:

Resolution: 1334pt x 750pt refers to 1136 physical pixels vertically and 750 horizontally on the screen.

Screen size: 4.7in Note that inches are a unit of length, not area. 4.7 inches refers to the diagonal length of the screen, and 1 inch equals 2.54cm.

Screen pixel density: 326PPI refers to the number of pixels per inch of the screen. In a display, Dpi =ppi. Dpi emphasizes points per inch. Also, screen pixel density = resolution/screen size

And then, let’s look at the other units.

Device-independent pixels: Device-independent pixels, unlike device pixels (physical pixels), are virtualized. For example, CSS pixels, when we say 10px, actually mean that. It is important to note that physical pixels are not available to developers, they are something that exists naturally, as many as they can be.

Device Pixel Ratio: DPR, for short, is a value we often see at the top of mobile debugging on the Google Console. Device pixel ratio = Device pixel/CSS pixel (vertical or horizontal). It can be obtained from JS: window.devicepixelRatio

Different viewports on PC and mobile

Note: The pixels mentioned below are CSS pixels. And scaling is not considered by default.

Layout viewport

For those of you who have written CSS, we set width:100%; height:100%; It is not invalid. We all know that 100 percent is something that you inherit from the parent. So where does it come from here?

In PC browsers, there is something that constrains the CSS layout viewports, also known as initial containment blocks. This is where all width and height inheritance comes in. Margin and padding aside, the layout viewport is the same width as the browser viewport, and the width of the browser itself.

But on mobile, it’s a different story.

The following example is illustrated without meta tags.

If we now make a layout of around 28, then on the PC side of the display is very perfect, there is nothing to say.

If it is on the mobile terminal, here to iphone6 as an example to explain:

The legend is as follows:

The code is as follows:

* {
    margin: 0;
    padding: 0;
}

html,
body {
    height: 100%;
    width: 100%;
}

.left {
    float: left;
    width: 20%;
    height: 100%;
    background: red;
}

.right {
    float: right;
    width: 80%;
    height: 100%;
    background: green;
}
----
<body>
    <div class="left"></div>
    <div class="right"></div>
</body>Copy the code

Here we see why the body height is 980px and the browser width is only 375px, but where does the 980px come from?

In fact, 980px is the mobile layout viewport.

On mobile, by default, the layout viewport is much wider than the width of the browser. The two viewports are independent of each other. Why is that? Imagine if a web page is not mobile-friendly and the width of the viewport is equal to the width of the browser by default when the user is reading it. In other words, if a div is 20% wide, it will show the user 196px pixels at 980px layout viewport width, and 75px at 375px width, showing a huge difference in size.

As a result, in order to make web pages look good even on small screens, browser manufacturers set the width of the layout viewport to be very large, usually between 768px and 1024px. The most common width is 980px. The width can be through the document. The documentElement. ClientWidth.

Visual viewport

For visual ports, this is what is presented to the user, and it is the number of CSS pixels that the user sees in the area of the web page. Since the user can zoom in and out, this viewport is not a major concern for developers.

Note that zooming on the mobile side does not change the width of the layout viewport. When zooming out, the screen covers more CSS pixels and the viewport becomes larger, and vice versa.

On the PC side, zoom corresponds to the layout width and visual window width are linked. The browser width itself is fixed, regardless of how you zoom.

If you’re still confused about the width above, here’s a chart to help you figure it out.

The following tables are based on the width of the browser window horizontally:

For PC:

For mobile:

Ideal viewport

Above, the layout viewport is obviously unfriendly to users, completely ignoring the phone’s original size.

So Apple introduced the concept of the ideal viewport, which is the ideal layout viewport size for a device. The ideal width for a web page user in an ideal viewport. The user does not need to zoom when entering the page.

Obviously, the ideal width is the width of the browser (screen).

So here’s the code:

<meta name="viewport" content="width=device-width">Copy the code

However, this code is not perfect, because in Internet Explorer, it is affected by the switch between landscape and portrait. To solve this compatibility problem, I add a final sentence, which has the present:

<meta name="viewport" content="width=device-width,initial-scale=1">
Copy the code

Width =device-width sets the layout viewport to the width of the browser (screen).

Initial-scale =1 means that the initial scale is 1, which also sets the layout viewport size to the scaled size. The zoom size is based on the width of the screen, so it has the same effect as width=device-width.

In addition, it is worth mentioning that when we do the media query, the width value of the query is actually the width value of the layout viewport.

Retina Screen & normal screen, the origin of blur

Specific performance of DPR

Sometimes we find that the display is fine when we’re working with a particular model. But as soon as I switched to another phone, there was a blur, especially in the picture.

In fact, the problem involves one of the attributes mentioned above: the device pixel ratio, commonly known as DPR. Here is the performance of DPR:

Let’s say you have an iphone6 that has a device size of 375×667 pixels, a DPR of 2, and a size of 4.7in. The physical pixels are 750×1334. Similarly, we also have an unknown device with a device independent pixel of 375×667 and a size of 4.7in, but with a DPR of 1, the physical pixel is 375×667.

So their screens look like this:

CSS pixels appear to be the same size on different screens, both normal and Retina. (If you don’t understand this, you can write a 2px square using the Google Console mobile device debugging, switching back and forth between different devices, you will see that the size is actually the same. At first I always thought that the actual width and height of the CSS pixel would be different on different devices due to DPR.

The difference is that one CSS pixel corresponds to the number of physical pixels (covered).

So, if we want to display a CSS style on these two screens:

width: 2px;
heigth: 2px;Copy the code

On a normal screen, that is, a screen with a DPR of 1, one CSS pixel corresponds to (overlays) one physical pixel. On a Retina screen, one CSS pixel corresponds to four physical pixels. In other words, a device with a DPR of 2. Take a look at the chart below:

A simple understanding is that a square of 2cmx2cm is cut into four pieces, and then when DPR is 2, the four pieces are cut into four pieces respectively, but the total area remains the same.

Generation of ambiguity

Knowing that the physical pixels covered by one CSS pixel can be different, it’s easy to understand why blurring can occur.

Here’s another term: bitmap pixel.

A bitmap pixel is the smallest unit of data in a raster image (e.g. PNG, JPG, GIF, etc.). Each bitmap pixel contains some display information of its own. (e.g., display position, color value, transparency, etc.)

In theory, every bitmap pixel corresponds to every physical pixel, so that the image is perfectly clear.

But as mentioned above, on retina screens, there will be multiple physical pixels for every bitmap pixel.

Again, take iphone6 as an example, 1 bitmap pixel corresponds to 4 physical pixels. Since a single bitmap pixel is the smallest unit of data, it can no longer be sliced. So in order to be able to display, you have to take the nearest color, which leads to the so-called picture blur problem. As follows:

How to solve

Obviously, because the bitmap pixel is not enough to produce blurred situation, the solution is very simple, is to use the same multiple size as the DPR image. For iphone6, for a 200×300 img tag, the original image should be 400×600 in size.

So when loading the IMG tag, the browser will automatically halve the CSS pixels for every 1px, which means that the CSS pixels are still 1:1: physical pixels, no blur.

This practice is actually one of the most important principles for the Retina adaptation team, which will be discussed later. Let’s not say it here.

other

Think about it the other way around. What would happen if a normal screen, with a DPR of 1, also used twice as many images?

Obviously, under the normal screen, the number of physical pixels corresponding to the 200×300 IMG tag is 200×300, while the number of bitmap pixels corresponding to the double image is 200x300x4, so one physical pixel corresponds to four bitmap pixels, so its color selection can only be reduced by a certain algorithm. The result is an image with only a quarter of the total number of pixels in the original image. The image will not look blurry to the naked eye, but it will look slightly off-color. (It’s a fuzzy reverse process.)

In pictures, it is:

Here is a demo from a blog post on the Internet to illustrate the above issues.

Above is a 100×100 image in 100×100, 50×50, and 25×25 containers under the Retina screen.

The difference of boundary pixels can be seen through the color picker magnifying glass:

In Figure 1, the color of the boundary pixel is taken nearby, and the color value is between red and white, which is too light, and the picture will look blurred (which can be understood as image stretching).

In figure 2, the picture is normal and clear.

In Figure 3, the color of the boundary pixel is taken nearby, and the color value is between red and white, which is too thick, and the picture looks chromatic aberration.

Mobile team flexible. Js layout

Nowadays, the traditional REM layout adapted to mobile terminals has been gradually replaced by a flexible layout of The Mobile Mobile team.

The specific implementation method and details here are not spread out, specific reference to w3CPlus an article, easy to read and understand.

Here I’d like to analyze the meaning and reasons of flexibility.js.

After reading the article, I believe that we should be more familiar with the process of the entire development of adaptation.

Let’s say you want to fit an iphone6 device. The above has said the various parameters of iphone6, here is no longer described, the need to move up to view.

So:

The designer gave the design 750px wide (note that this is 750px not 375px)
The front end engineer starts the reduction at 750px
Convert px width and height to REM
Use PX fonts instead of REM
Flexible. Js will automatically judge the DPR to scale and shrink the entire layout viewport

Rem layout and font processing

As can be seen from flexibs.js, REM is used in wide high school to ensure equal scale of layout in devices of different width and size.

Why use PX instead of REM?

First of all, if you’ve ever used REM units, you’ll notice that rem units have all sorts of weird numbers due to their different sizes. The most obvious ones are more decimal places, such as 13.755px. In browsers, the calculation of decimal points varies from browser to browser, and some font-size values with decimal numbers do not appear clear enough in certain browsers.

Second, we don’t want to have the same amount of fonts underneath the small screen as we do on the big screen. In addition, if REM is used, due to the existence of equal proportion, there will be smaller fonts on the small screen under the small screen, which is not conducive to our better reading and violates the original intention of adaptation. Therefore, for font adaptation, it is better to use PX and media query for adaptation.

Font-size: 16px; line-height: 20px; “> < span style =” font-size: 16px;

@mixin font-dpr($font-size) {
    font-size: $font-size;
    [data-dpr="2"] & {
        font-size: $font-size * 2;
    }
    [data-dpr="3"] & {
        font-size: $font-size * 3; }}Copy the code

Due to the different DPR for Retina display, we wanted the font to be the same size, so we increased the DPR multiple of the font, so that when we reduced the DPR by a factor, the font would be the same size as the design draft, and it would be the same size on different phones.

Retina processing with Android phones

As you can see from the flexible. Js code, the flexible layout is only suitable for iPhone, and the DPR is mandatory for all Android devices by default.

So, for this reason, many friends may have such a question: why does Android not use retina screen, android does not have the problem of blurring?

In fact, the nature of the ambiguity is due to DPR, and the DPR of android phones varies from device to device. In other words, there is also ambiguity on Android phones. But it doesn’t have a Retina screen, so many people think android phones don’t have that problem.

So the question is again? If there’s a problem with blurring, why don’t Android phones adapt?

If you are interested, you can take a look at android phones in Greater China. DPR parameters are varied from 1 to 4, including such weird numbers as 1.75 and 2.75. Therefore, I think it is more efficient and profitable to set all Android phones to 1.

Of course, some people have improved the flexible. Js, which is suitable for Android phones with normal DPR, that is, only suitable for Android devices with integer DPR. Ignore those weird devices with a DPR of 1.75. It’s not that hard to do, if you’re interested.

Responsive versus adaptive selection

Finally, there are various explanations on the Internet for the difference between responsive and adaptive.

In my opinion, there is no need to make it so complicated. A friend of Zhihu said it in plain English.

Responsivity is an adaptive design for devices with different resolutions, using @media rules as the main means, while adaptive ignores the proportional layout of @media and aims to adapt to different browser window sizes.

As a result, we find that today’s large websites, such as Taobao, are no longer responsive. What does that mean?

We will find that taobao mobile and web uses two domain names, that is to say, different clients no longer share the same DOM structure. It’s about differentiating and adapting. It then redirects based on the client type each time the user accesses it.

Why is that?

Just think about taobao, a large website, there are a lot of commodity items under one page, and the DOM structure of each commodity item is very complex, and the INFORMATION displayed on THE PC terminal is often more than that on the mobile terminal. If you do not separate the two sets and use the responsive style directly, a lot of the DOM displayed on the PC side will be hidden on the phone side, so that the DOM is not used, but loaded. In this era of traffic and speed first, code redundancy aside, the extra load of these useless code consumption of traffic, in a sense, has lost a lot of benefit.

That’s all for this article.

The article has reference, reference links will be put out here.

The experience and knowledge of our predecessors are very valuable. What we need to do is to stand on the shoulders of giants to refine these things and have a better understanding, thinking and exploring new horizons of knowledge.