What you need to know about adaptation - MobileWeb adaptation summary

Straight to the point, this article will summarize the adaptation methods of MobileWeb, which we often call H5 pages, mobile pages, WAP pages, webview pages, etc.

The pages discussed in this article refer to pages designed specifically for mobile devices, not responsive layouts that are compatible with all devices. The device-width mentioned in the article refers to the width value in the viewport meta tag, which is the value specified by the browser. For the corresponding values ​​of common models, please refer to Screen Sizes.

What effect does adaptation achieve?

On mobile devices of different sizes, the page "achieves a relatively reasonable display (adaptive)" or "maintains a uniform proportional scaling effect (looks similar)".

What factors should be focused on in adaptation?

Generally speaking, what we need to pay attention to are: fonts, height and width spacing, and images (icons, pictures).

Among them, images are relatively complex. There are also relatively mature solutions for traffic and clarity issues on the Internet, such as vectorization, fontization, image-set, etc., which will not be discussed in depth here. To meet the needs of rapid development, we use a relatively lazy method: use CSS to limit images to elements (img images use [max-]width: 100% and background images use background-size), and layout is only performed on elements.

Another thing to consider is what width the designer uses when designing the visual draft, so as to meet the needs of the design itself and allow the front-end development to easily cut and adapt the pictures.

For example

Focusing on these three elements, we use a small example to illustrate the implementation of the three solutions to be introduced next. The effect to be achieved according to the 640px standard is shown in the figure:

app.jpg

Fixed height, adaptive width

This is the most common approach at present, which belongs to adaptive layout. The viewport width is set to device-width, and the layout is based on the visual draft with a smaller width (such as 320px). The vertical height and spacing use fixed values, and the horizontal direction uses a mixture of fixed values ​​and percentages or uses elastic layout, ultimately achieving the effect of "horizontally stretching or filling blanks when the mobile phone screen changes". Image elements are scaled using fixed values ​​or background-size according to the container.

After a quick look at the homepages of some major companies, I found that Baidu, Tencent, Facebook, and Twitter all adopted this solution.

Key points:

The reason for using small width as a reference is that if the layout satisfies the small width, when the screen becomes wider, simply fill the blank space; if the opposite is true, it may cause "squeezing", considering the header area, the logo is measured on the left and the horizontal nav is measured on the right.

There is a contradiction between needing a small-width layout and a large-width image.

320px is too narrow and not conducive to page design; it can only design horizontally stretched element layouts, which has many limitations.

Good compatibility.

The implementation is relatively simple. The sizes in the style are set to half the size of the visual draft. Check out the effect and code.

Fixed width, viewport scaling

The visual draft, page width, and viewport width use the same width, and use the browser's own zoom to adapt. The page style (including image elements) is completely based on the size of the visual draft, using fixed units (px, em).

advantage:

Simple development: Zooming is left to the browser, and the images are cut completely according to the visual draft.

Accurate restoration: Absolute proportional scaling can accurately restore the visual draft (without considering the clarity).

Convenient testing: Most tests can be completed on the PC side, and the mobile side only needs to adjust some details as appropriate (such as alignment problems caused by different fonts when icons and fonts are mixed).

Problems:

Pixel loss : For some mobile phones with lower resolutions, the device pixels may not reach the specified viewport width, and the screen rendering may be inaccurate. The most common problem is that the border "disappears", but with the update of mobile phone hardware, this problem will become less and less.

Scaling failure : Some Android devices cannot scale the viewport according to the width value in the meta tag, and need to be used in conjunction with initial-scale.

Text wrapping: This problem occurs in models with invalid zooming. To make it easier to read text, some phones wrap text when it reaches the edge of the viewport (not the edge of the element container). When the viewport width is corrected, the browser does not redraw the text correctly, so it is found that the text does not fill the entire line. This problem occurs in some commonly used paragraph text tags.

The zoom failure problem requires dynamic setting of initial-scale through js

 var fixScreen = function() {
 var metaEl = doc.querySelector( 'meta[name="viewport"]' ),
 metaCtt = metaEl ? metaEl.content : '' ,
 matchScale = metaCtt.match(/initial\-scale=([\d\.]+)/),
 matchWidth = metaCtt.match(/width=([^,\s]+)/);
 if ( metaEl && !matchScale && ( matchWidth && matchWidth[ 1 ] != 'device-width' ) ) {
 var width = parseInt(matchWidth[ 1 ]),
 iw = win.innerWidth || width,
 ow = win.outerWidth || iw,
 sw = win.screen.width || iw,
 saw = win.screen.availWidth || iw,
 ih = win.innerHeight || width,
 oh = win.outerHeight || ih,
 ish = win.screen.height || ih,
 sah = win.screen.availHeight || ih,
 w = Math.min(iw,ow,sw,saw,ih,oh,ish,sah),
 scale = w / width;
 if ( ratio < 1 ) {
 metaEl.content += ',initial-scale=' + ratio + ',maximum-scale=' + ratio + ', minimum-scale=' + scale + ',user-scalable=no' ;
 }
 }
 }

The text wrapping problem can be solved by using CSS styles.

Since this solution uses a fixed width value, what is the appropriate value? The first thing to consider is the mainstream resolution, which can be referred to the data of Screen Sizes and Umeng Index; the second thing to consider is the design size commonly used by the design department, and finally determine a suitable value after comprehensive coordination.

Here we use 640px to implement the example, see the effect and code.

Using rem layout

According to a certain width, the rem value is set (i.e., the font-size of HTML). The size of any element on the page that needs to be flexibly adapted is converted to rem for layout; when the page is rendered, the effective width of the page is calculated, the rem size is adjusted, and dynamic scaling is performed to achieve the adaptation effect. With this solution, the initial-scale can also be set according to the devicePixelRatio to enlarge the viewport, so that the page is rendered according to physical pixels and the clarity is improved.

advantage:

The clarity is high and can reach the clarity of physical pixels.

Can solve the "1 pixel" problem caused by DPR.

Backward compatibility is good, and the solution is still applicable even if the screen width increases and the PPI increases.

shortcoming:

The adaptation js needs to enter as early as possible to reduce (avoid) redrawing caused by viewport changes.

Some Android devices will drop the rem fractional part.

Requires precompiled library for unit conversion.

During development, both CSS and JS use 16px as the base to convert rem. With the help of precompiled libraries (taking scss as an example), we set a dynamic size unit $ppr: 750px/16px/1rem, that is, pixel per rem. Any place where flexible size is used is written as: width: 100px/$ppr.

The method of dynamically adjusting rem is as follows:

 var fixScreen = function() {
 var metaEl = doc.querySelector( 'meta[name="viewport"]' ),
 metaCtt = metaEl ? metaEl.content : '' ,
 matchScale = metaCtt.match(/initial\-scale=([\d\.]+)/),
 matchWidth = metaCtt.match(/width=([^,\s]+)/);
 if ( !metaEl ) { // REM  
 var docEl = doc.documentElement,
 maxwidth = docEl.dataset.mw || 750 , // ***page width per dpr  
 dpr = isIos ? Math.min(win.devicePixelRatio, 3 ) : 1 ,
 scale = 1 / dpr,
 tid;
 docEl.removeAttribute( 'data-mw' );
 docEl.dataset.dpr = dpr;
 metaEl = doc.createElement( 'meta' );
 metaEl.name = 'viewport' ;
 metaEl.content = fillScale(scale);
 docEl.firstElementChild.appendChild(metaEl);
 var refreshRem = function() {
 var width = docEl.getBoundingClientRect().width;
 if (width / dpr > maxwidth) {
 width = maxwidth * dpr;
 }
 var rem = width / 16 ;
 docEl.style.fontSize = rem + 'px' ;
 };
 //...  
 refreshRem();
 }
 }

The code implementation mainly refers to the adaptation method of Taobao touch screen version to view the effect and code. The writing method of scss can be found here.

Note that for smaller background images (such as some icons), do not use a specific rem value for background-size, as this will cause the edges to be lost after cropping. Instead, use a cut image of the same size as the element and set background-size: cover|contain to scale it.

Summarize

In general, there is no perfect solution at present. These are just general solutions that try to meet the needs of rapid development and simple adaptation. Some more detailed issues (such as font dot size and inflexible fixed value requirements) are not discussed. In the actual development process, we should comprehensively consider factors such as project type, resource cost, personnel coordination, etc. to choose the appropriate solution.

The mobile-util.js used in the code implementation integrates fixed width and rem adaptation. The source code is here.