Content "width = 640, user-scalable = no" and then perform a fixed-size px design? -

And then the fixed size px design? In fact, we can achieve adaptive layout on the mobile phone. Aren't we usually viewportcontentwidth640, use content "width = 640, user-scalable = no", and then conduct a fixed-size px design? It can also achieve adaptive layout on the mobile phone
Aren't we usually viewport content = "width = device-width? Is there any pitfalls above, in the future, if I use t content = "width = device-width css3 for media queries or use content" width = 640, user-scalable = no. I need to be compatible with the webview reply content of the mobile browser and apk: Conclusion: content "width = 640, user-scalable = no "is a good solution. Lychee FM, everyone is a podcast. This solution is used by the mobile site

Fixed width, viewport Scaling

The visual draft, page width, and viewport width use the uniform width and use the browser's own scaling to adapt. The page style (including image elements) is based on the size of the visual draft, and the unit of value (px, em) can be used.

Advantages:

• Simple DevelopmentZooming the image to the browser and cutting the image completely according to the visual draft.
• Precision RestorationAbsolutely proportional scaling allows you to accurately restore the visual draft (without considering the definition ).
• Easy to testMost tests can be completed on the PC end, and the mobile phone end only needs to adjust some details as appropriate (the alignment problem caused by different fonts when the ratio and font are mixed ).

Problems:

• Pixel lossFor mobile phones with lower resolution, the device pixel may not reach the specified viewport width, and the screen rendering may be inaccurate. The common problem is that the border disappears. However, with the update of mobile phone hardware, this problem will become fewer and fewer.
• Scaling failureSome Android devices cannot normally use meta tags.WidthTo scale the viewport.Initial-scale.
• Text linesSome mobile phones are collapsed when the text reaches the edge of the viewport (the edge of a non-element container) to facilitate text reading, when the viewport width is corrected, the browser does not correctly redraw the page, so it is found that the text is not full. This problem occurs in some common field-specific text labels.

Scaling failure issues need to be dynamically set through jsInitial-scale.

Use rem Layout

Set the rem value according to a specific width (that is, the htmlFont-size), The size of any element on the page that needs to be elastically adapted is converted to rem for layout. When the page is rendered, it is calculated based on the effective width of the page to adjust the rem size, dynamic Scaling to achieve adaptation. This solution can also be used accordingDevicePixelRatioSetInitial-scaleTo enlarge the viewport, so that the page is rendered by physical pixels to improve the definition.

Advantages:

• High Definition, which can achieve the resolution of physical pixels.
• It can solve the "1 pixel" problem caused by DPR.
• Backward compatibility is good, even if the screen width is increased and the PPI is increased, this solution is still applicable.

Disadvantages:

• Js adaptation requires entering as early as possible to reduce the repainting caused by viewport changes.
• Some Android devices may lose the rem fractional part.
• Requires a pre-compiled library for unit conversion.

(MobileWeb adaptation Summary ) I will not talk about it much. I strongly recommend you read an article just written a few days ago: use Flexible to adapt the terminal of the H5 page of mobile Taobao. You may be able to find the desired answer:

In essence, this method scales the interface linearly to adapt to screens of different sizes. It is acceptable for devices within a certain size range. However, it is not suitable if you want to develop a page that spans tablets and mobile phones. Because the size difference between the mobile phone and the tablet screen is too large, it will lead to a large scaling, but the interface elements are not harmonious. Therefore, it is best to adopt a non-linear scaling method.

// First check the browser type var browser = getBrowser (); if (window. top = window) {var s, t, sw; if (browser = 'gecko ') {s = calcRato (Math. min (screen. width, screen. height); document. write ('
  ');} Else if (browser = 'think') {document. write ('
  '{}Document.doc umentElement. style. zoom = calcRato (Math. min (screen. width, screen. height);} else {t = document. createElement ('meta'); t. name = 'viewport'; t. content = 'width = device-width, user-scalable = no, initial-scale = 1'; document. head. appendChild (t); sw = Math. min (screen. width, screen. height); if (Math. min (screen. width/window. innerWidth, screen. height/window. innerHeight)> 1) invalid document.doc umentElement. style. zoom = calcRato (sw/devicePixelRatio);} else {s = calcRato (sw); t. content = 'width = '+ 100/s +' %, user-scalable = no, initial-scale = '+ s ;}} function calcRato (sw) {// discrete zoom Level var step = 0.125; // The reference width is 320 pxvar zoom = sw/320; // linear algorithm if (zoom> 1) is not used for zoom) {zoom = Math. floor (Math. sqrt (zoom)/step) * step;} return zoom ;}

Yes, I also use this method for convenience. However, due to the aspect ratio and zoom ratio, the screen size of many mobile phones is not high enough for element positioning and layout, therefore, we still need to adjust the details of media queries. We can use this code to write the hybrid app. The core difference is that it does not have media queries, and the mobile phone and tablet are all long, proportional scaling does not look at the effect carefully (after all, it will be distorted). If you only need to develop a page adapted to most models, I think this is quite good.