Detailed description of HTML meta viewport attribute_HTML/Xhtml_Web page production

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. In a very small window (which would break the layout of a webpage that is not optimized for mobile browsers), users can pan and zoom to see different parts of the webpage. 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: control viewport The size can be specified as a value, such as 600, or a special value such as device-width, which is the width of the device (in CSS pixels when scaled 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 zoom

Some questions about viewport

Viewport is not just 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 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 physical device True resolution on, not allowing user scaling. 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, aquos phone (android system) from an unknown manufacturer, 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 the viewport is set, for example, user-scalable=no is simply set, such as , then the width will still be displayed as 980 under ios (that is, it will be scaled by dpi by default), but it will not be displayed under android and winphone. After scaling, the browser resolution is consistent with the actual 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. However, under Android, the width you set is invalid. What you can set is a special field target-densitydpi. You can refer to target-densitydpi for more information. Check out this article: http://hi.baidu.com/j_fo/blog/item /748361279ebccd18908f9d7d.html. In other words, there are three variables: browser width, device real 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. 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: , the user cannot be prevented 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. Being compatible 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 horizontal or vertical screen, it will automatically adjust the dpi. Regardless of the horizontal screen or the vertical screen, it can ensure that the browser width is equal to the value set in the viewport. , so when the screen is in landscape or portrait mode, 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 is 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.