Lazy people must be mobile end-width web-matching scheme

Today's mobile devices have a complex resolution. Previously only Andro had a variety of adaptation issues, now the iphone also has three mainstream resolutions, and the future of the iphone 7 May play a different way. How to Status quo, with a few simple lines of code to support a wide range of screen resolution? Today, we will introduce a kind of lazy people must be a mobile end-width Web page adaptation method.

First look at the following line of code:

<meta name="viewport" content="width=device-width, user-scalabel=no">

Has the mobile development experience of the classmate is not very familiar with the above code? It may be one of the most common settings for responsive design viewport , and the method I present today also leverages META tag settings viewport to support most mobile screen resolutions.

Goal

• Just by configuring the <meta name="viewport"> mobile site to be designed and implemented at a fixed width, you can see design-compliant pages on any major mobile device, including Android 4+, IPhone 4+.

Test equipment

• Samsung Note II (Android 4.1.2)-Real machine
• Samsung Note III (Android 4.4.4-api)-Genymotion virtual machine
• IPhone 6 (IOS 9.1)-Real machine

Iphone

IPhone adaptation is simple and only needs to be set width . Like what:

<!-- for iPhone --><meta name="viewport" content="width=320, user-scalable=no" />

This way your page will display a fixed width of 320 pixels on all iphones, whether it's an iphone 6 with a width of 375 pixels or a 414-megapixel iphone 6 Plus.

Android

The adaptation on Android has been dubbed the mobile side of IE, there are indeed many compatibility issues. Android with 4.4 version for a watershed, first say a relatively good deal of Android 4.4+

Android 4.4+

For compatibility reasons, Android 4.4 discards the target-densitydpi attribute, which only takes effect on Android devices. If you are interested in this deprecated attribute, you can look at these two links:

• Support for target-densitydpi are removed from WebKit
• Bug 88047-remove support for target-densitydpi in the viewport meta tag

We can set it up like on the IPhone width=320 to achieve the 320px fixed width page design we want.

<!-- for Android 4.4+ --><meta name="viewport" content="width=320, user-scalable=no" />

Android 4.0 ~ 4.3

As a relatively old version of Android, it has a poor support for the width attribute in meta. In Samsung Note II, for example, its device-width is 360px. If you set the width (hereinafter abbreviated) in viewport vWidth to a value that is less than or equal to 360, it will not have any effect, and a vWidth value greater than 360 will not cause the screen to scale, but a horizontal scroll bar appears.

If you want to support Android 4.0 to 4.3, you still have to rely on the page zoom, and the property that was revoked: target-densitydpi .

target-densitydpi

TARGET-DENSITYDPI altogether has four kinds of values: low-dpi (0.75), medium-dpi (1.0), high-dpi (1.5), device-dpi. In Android 4.0+ devices, device-dpi is generally 2.0. I used the Samsung Note II device (Android 4.1.2) on hand to do a series of experiments and got the following form:

r>

target-densitydpi	Viewport:width	Body Width	screen viewable range width
low-dpi (0.75)	vwidth <=-	+	+
;	vwidth > *	vwidth*	+
medium-dpi (1.0)	vwidth <=
	vwidth > high-dpi	vwidth*
(1.5)	vwidth <=	540	540
	< vwidth <= 540	vwidth*	V width*
	vwidth > 540	vwidth*	540
DEVICE-DPI (2.0) * *	vwidth <= 32	720	720
	0 < Vwidth <= 720	vwidth*	vwidth*
	vwidth > 720	vwidth*	720

• Vwidth*: Refers to the same value as the width set in the viewport.
• DEVICE-DPI (2.0) * *: in Android 4.0+ devices, device-dpi is generally 2.0.

The first thing you can see is that the 320px is a particularly bizarre threshold, something that goes beyond what we expected after this threshold. This value is taken into account in target-densitydpi = device-dpi a comprehensive consideration. If you want to use 320px as the width of the page, I suggest you set it for Android version 4.4 or less width=321 .

If the body width exceeds the width of the screen's viewable range, a horizontal scroll bar appears. This is not the result we expect, so we have to use the Zoom property initial-scale . The calculation formula is as follows:

Scale = Devicewidth/vwidth

This formula has to be implemented using JS, and finally we can get the code to fit the Android 4.0 ~ 4.3 width:

VarMatch,Scale,Target_width=320;If(Match=Navigator.UserAgent.Match(/android (\d+\.\d+)/)){If(Parsefloat(Match[1])<4.4){If(Target_width==320)Target_width++;var scale = window. Screen. Width /target_widthdocument. Queryselector ( "meta[name=" viewport "] ' ).  Setattribute ( ' content '  ' width= ' + target_width +  ' Initial-scale = ' + scale +  ' target-densitydpi=device-dpi ' ); }}             /span>                

Which TARGET_WIDTH is the width you expect, and note that this code is only valid between 320-720px.

The pits in the zoom

If it's an iPhone or Android 4.4+ machine, be very cautious about using scale-related attributes, including initial-scale , maximum-scale and minimum-scale . Either make sure scale = devicewidth/vwidth, or try not to use it. Take a look at an example:

In cases where scaling is not guaranteed, the performance of the two is inconsistent even if the same is set width initial-scale . The specific two models adopted by the strategy how I have not explored out, interested classmates can study to see. The easiest way to do this is to not set scale-related properties on IPhone and Android 4.4+.

Summarize

Combined with all of the above analysis, you can use this JS code to fit all iphone and Android 4+ phone screens:

VarMatch,Scale,Target_width=320;If(Match=Navigator.UserAgent.Match(/android (\d+\.\d+)/)){If(Parsefloat(Match[1])<4.4){If(Target_width==320)Target_width++;VarScale=Window.Screen.Width/Target_width;Document.Queryselector(' Meta[name= ' viewport "] ').setattribute ( ' content '  Width= ' + target_width +  "Initial-scale = ' + scale +  ' target-densitydpi=device-dpi ' ); }} else {document queryselector ( ' meta[name= "viewport"] ' ). setattribute ( ' content '  ' width= ' Span class= "o" >+ target_width) }       

If you don't want your page to be manually scaled by the user, you can add it user-scalable=no . However, it is important to note that this property is not valid on some Android models.

Other references

1. Supporting Different Screens in Web apps-android developers
2. Viewport target-densitydpi support is being deprecated

Appendix-Test Page

Interested students can take this test page to measure their own mobile phone, do not forget to change viewport oh.

<! DOCTYPE html>lang="EN"><metacharset="UTF-8"><metaName="Viewport"Content="Width=250, initial-scale=1.5, User-scalable=no"><title>document</title><style>Body{Margin:0;}Div{Background:#000;Color:#fff;Font-size:30px;Text-align:Center;}. Block{Height:50px;Border-bottom:4pxSolid#ccc;}#first{Width:100px;}#second{Width:200px;}#third{Width:300px;}#fourth{Width:320px;}#log{Font-size:16px;}</style><body><divId="First"class="Block">100px</div><divId="Second"class="Block">200px</div><divId="Third"class="Block">300px</div><divId="Fourth"class="Block">320px</div><divId="Log"></div><script>functionLog(Content){VarLogcontainer=Document.getElementById(' Log ');VarP=Document.CreateElement(' P ');P.textcontent = contentlogcontainer. Appendchild (p} log ( ' body width: ' + document. Body. Clientwidth) log (document.< Span class= "NX" >queryselector ( "[name=" viewport "] ' ).  Content) </script></body></ Html>                

The copyright of this article belongs to the author Shangyang, using Attribution-noncommercial 3.0 License. Any person may reproduce, share, but not be used without permission for commercial purposes; reprint please specify the source. Thanks for cooperating!

Lazy people must be mobile end-width web-matching scheme