HTML meta viewport attribute description

What is a Viewport

Mobile browsers place web pages in a virtual "window" (viewport), which is usually wider than the screen. This way, there is no need to squeeze each web page into a small window (which would destroy the layout of web pages that are not optimized for mobile browsers). Users can view different parts of the web page by panning and zooming. The mobile version of Safari has recently introduced the viewport meta tag, which allows web developers to control the size and zoom of the viewport. Other mobile browsers also basically support it.

Viewport Basics

A commonly used viewport meta tag for a mobile-optimized page looks like this:

<meta name=”viewport” content=”width=device-width, initial-scale=1, maximum-scale=1″>

width: controls the size of the viewport. You can specify a value, such as 600, or a special value, such as device-width, which is the width of the device (in CSS pixels when the zoom is 100%).
height: Corresponding to width, specifies the height.
initial-scale: The initial zoom ratio, that is, the zoom ratio when the page is loaded for the first time.
maximum-scale: The maximum scale to which the user is allowed to zoom.
minimum-scale: The minimum scale to which the user is allowed to zoom.
user-scalable: Whether the user can manually scale

Some questions about viewport

Viewport is not a unique attribute of iOS, but also exists on Android and Windows Phone. The problem they are trying to solve is the same, which is to ignore the actual resolution of the device and directly reset the resolution between the physical size and the browser through dpi. This resolution has nothing to do with the resolution of the device. For example, if you take a 3.5-inch 320 * 480 iPhone 3 gs, a 3.5-inch 640 * 960 iPhone 4, or a 9.7-inch 1024 * 768 iPad 2, although the resolutions and physical sizes of the devices are different, you can make them have the same resolution in the browser by setting the viewport. For example, if your website is 800px wide, you can set the viewport width to 800 to make your website fully displayed on these three different devices.

I believe that everyone who has a little knowledge of viewport should have understood the above knowledge. This is not the point I want to talk about today. What I want to explain is some differences in the viewport performance on iOS and Android.

A quick search on the Internet about viewports yields basically all the following information:

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

This code means that the width of the viewport is equal to the actual resolution on the physical device, and the user is not allowed to zoom. All mainstream web apps are set up like this. Its function is actually to deliberately abandon the viewport and not scale the page. In this way, the dpi must be the same as the actual resolution on the device. Without any scaling, the web page will appear more delicate. Those who are familiar with Photoshop should all know what it looks like when you scale a 1000 * 1000 picture directly to 500 * 500, right? There is no way to avoid image distortion.

But the application I want to make is just the opposite. It needs to use viewport and zoom. Regardless of the actual resolution, regardless of the physical size, I want to have a uniform resolution in the browser, without allowing the user to zoom. The devices I used for testing are: iPhone 4, iPad 2, HTC G11, Aquos Phone (Android system) of unknown manufacturer, Asus Android Pad, Dell Win Phone, and I encountered the following problems along the way:

1) If the viewport is not explicitly set, the default width is 980. If the width of all elements on the page is less than 980, the width is 980. If the widest position of the page exceeds 980, the width is equal to the maximum width. In short, the entire page can be displayed from left to right by default. If the viewport is set, for example, only user-scalable=no is set, such as <meta name="viewport" content="user-scalable=no" />, then the width will still be displayed as 980 on iOS (that is, it will be scaled by dpi by default), but it will no longer be scaled on Android and Windows Phone, and the browser resolution is consistent with the actual set resolution.

2) For iOS devices, setting the width can take effect, but for Android devices, setting the width does not take effect. On iOS devices, the scaling ratio, i.e., dpi, is automatically calculated based on the width you set and the actual resolution. However, on Android, setting the width is invalid. What you can set is a special field, target-densitydpi. That is, there are three variables: browser width, device actual width, and dpi. Let's simply use a formula to express the relationship between them (not a real relationship, just for simple explanation): device real width * dpi = browser width. Of the three variables here, device real width is a known value that we cannot manipulate. For the other two variables, we can set one to affect the other. In iOS, we can change the browser width, and the dpi is automatically generated. In Android, we can change the dpi, and the browser width is automatically generated. For Android, no matter how we set the width, it will not affect the browser width.

P.S.: Here I would like to talk about another strange problem: in HTC's G11 (I only have this one HTC phone, and have not tested other ones), if the DPI is set without explicitly setting the width, user-scalable=no will not take effect, that is to say: <meta name="viewport" content="target-densitydpi=300,user-scalable=no" />, which cannot prevent users from zooming in and out of the screen. We need to explicitly set the width value. Although this value has no effect on the browser resolution screen under Android (it still has an impact on iOS), we still need to set it, and this value must be greater than 320. If it is less than or equal to 320, user-scalable=no will not take effect. This problem only occurs on HTC's G11 phone, and does not occur on Aquos Phone. Compatibility with Android is really a headache @_@, and I don’t know how many pitfalls there will be in the future. On Windows Phone, the result is even stranger: if I set the viewport width to a value greater than 480, user-scalable=no will become invalid, but if I set it to a value less than 480, user-scalable=no will take effect. But no matter what value I set for the viewport width, it does not have the expected effect on the actual display width of winphone, and target-densitydpi has no effect either. If the width is set to less than 480, the screen will be scaled, but the reduction ratio is completely different from what I expected. I don't know what rule it follows to scale. I don't know if this is a problem with Winphone or Dell's implementation.

3) This item is directly related to the previous one: iOS devices will automatically adjust the DPI when the screen is in landscape or portrait mode. Whether in landscape or portrait mode, the browser width will be equal to the value set in the viewport. Therefore, the size of the content displayed on the page will automatically scale and change when the screen is in landscape or portrait mode. However, when the Android phone is in landscape or portrait mode, the DPI will not change, and the web page will not be scaled when the screen is in landscape or portrait mode. For this reason, iOS can ensure that the page will not have scroll bars in both horizontal and vertical orientations and will display full screen, but Android cannot guarantee this. If the page fills the screen horizontally, it cannot fill the screen vertically, and vice versa.

4) For iOS devices, if the width is defined and the widest part of the page exceeds the width, the width will be invalid and the page will still be displayed at the widest width (without scroll bar). But a very strange problem will occur at this time. After you switch the screen of your phone between landscape and portrait several times, you will find that your page is automatically enlarged and a scroll bar appears, but the enlarged width actually has nothing to do with the width you set. To prevent this from happening, you need to set the width to be greater than, or equal to, the widest part of the page.