Description of the meta viewport attribute in html web pages_HTML/Xhtml_Web page production

HTML meta viewport attribute description

What is Viewport

Mobile browsers place the page in a virtual "window" (viewport). Usually this virtual "window" (viewport) is wider than the screen, so that each web page does not need to be squeezed into a small window. (This will break the layout of web pages that are not optimized for mobile browsers.) Users can pan and zoom to see different parts of the web page. The mobile version of Safari browser 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 page optimized for mobile web pages is roughly as follows:

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 (unit is CSS pixels when scaling to 100%).
Height: Corresponding to width, specify the height.
initial-scale: the initial scaling ratio, that is, the scaling ratio when the page is loaded for the first time.
maximum-scale: The maximum scale the user is allowed to zoom to.
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 only a unique attribute on ios, there are also viewports on android and winphone. The problem they want to solve is the same, that is, ignoring the real resolution of the device and directly resetting 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 set the The viewport makes them have the same resolution in the browser. For example, if your website is 800px wide, you can set the width of the viewport to 800 so that your website can be displayed on the entire screen on these three different devices.

I believe that every student who has a little knowledge of viewport should already know the above knowledge. This is not the focus of what I want to say today. What I want to explain is some differences in the performance of viewport on ios and android.

Searching for knowledge about viewport on the Internet, basically all the information is as follows:

The meaning of this code is to make the width of the viewport equal to the real resolution on the physical device and not allow the user to zoom. All mainstream web apps are set up like this. Its function is to deliberately abandon the viewport and not scale the page. In this way, the dpi must be the same as the real resolution on the device. Without any scaling, the web page will appear higher. exquisite. Students who play PS should all know what it will look like when you directly scale a 1000 * 1000 picture to 500 * 500 points, right? The distortion of the picture cannot be escaped.

But the application I want to make is just the opposite. It needs to use viewport and zoom. No matter what the real resolution is, no matter what the physical size is, I want to have a uniform resolution in the browser and not allow the user to zoom. The devices I used for testing include: iPhone 4, iPad 2, HTC's G11, an unknown manufacturer's Aquos phone (Android system), ASUS's Android pad, and Dell's winphone. Then I encountered the following problems along the way:

1) If the viewport is not set explicitly, the width defaults to 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, then the width is equal to the maximum width. In short, the entire page can be displayed from left to right by default. If viewport is set, for example, user-scalable=no is simply set, such as , then the width will still be displayed as 980 under ios (i.e. By default, it will be scaled by dpi), but it will no longer be scaled under Android and Winphone. The browser resolution is consistent with the real setting resolution.

2) For ios devices, setting width can take effect, but for android, setting width will not take effect. For ios devices, the scaling ratio, that is, dpi, is automatically calculated based on the width you set and the real resolution. On Android, the width you set is invalid. What you can set is a special field target-densitydpi, that is, there are three Variables: browser width, device real width, 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. Among the three variables here, the device’s real width is a known value that we cannot operate. , we can set one of the other two variables to affect the other. In ios, what we can change is the browser width, and the dpi is automatically generated. In Android, what we can change is 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.

ps: Let me talk about another strange problem here: in htc's g11 (I only have this one htc phone, and I haven't tested the others), if the dpi is set without setting the width explicitly, then user-scalable= no does not take effect, that is to say: , which cannot prevent the user from scaling the screen. We need to set the width value explicitly. Although this value does not have any impact on the browser resolution under Android (it will still have an impact on iOS), we still have to set it, and this value must be greater than 320. If it is less than or equal to 320, user-scalable=no cannot take effect. This problem only occurs on htc's g11 phone, not on aquos phone. Compatibility with android is really a headache @_@, I don’t know how many pitfalls there will be in the future. On winphone, the result is even stranger: if I set the width of the viewport to a value greater than 480, user-scalable=no will be invalid, but if I set a value less than 480, user-scalable=no will take effect. But no matter what value I set for the width of the viewport, it does not have the expected impact on the width actually displayed by winphone, and target-densitydpi has no impact either. Set the width. If it is less than 480, the screen will scale, but the scaling ratio is completely different from what I expected. I don’t know what rules it scales according to. I don't know if this is a Winphone problem or a Dell implementation problem.

3) This article should be directly related to the previous one: when the iOS device is in landscape or portrait mode, it will automatically adjust the dpi. Regardless of the landscape or portrait screen, it can ensure that the browser width is equal to the value set in the viewport, so the browser width will be equal to the value set in the viewport. When the screen is turned on, the size of the content displayed on the page will automatically scale and change. When the Android phone is in landscape or portrait mode, the dpi will not change, and when the screen is in landscape or portrait mode, the web page will not be zoomed. For this reason, ios can ensure that horizontal and vertical screen pages will not have scroll bars and fill the screen, but Android cannot guarantee this. If the screen is full horizontally, it cannot be full screen vertically, and vice versa.

4) For iOS devices, if the width display is defined and the widest position of the page exceeds the width, the width will be invalid and will still be displayed according to the widest width (there will be no scroll bar). But a very strange problem will arise 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 in fact, the enlarged width is not the same as the width you set. It doesn't matter. To prevent this, you need to set the width to be larger than, or the same as, the widest part of the page.