CSS Viewport 2

In this mini-series article I will explain viewport, and how the width of many important elements works, such as elements, including Windows and Screens.

In this article, let's talk about mobile browser Content. If you are completely new to mobile development, I suggest you first read the first article on desktop browser, first in the familiar environment to warm up.

Problems with mobile browsers

When we compare mobile browsers and desktop browsers, the most obvious difference is the screen size. A Web site designed for a desktop browser appears in a mobile browser significantly less than it appears in a desktop browser, whether it is scaled until the text is too small to read, or only a small portion of the site is displayed in the appropriate size on the Screen.

The screen of a mobile device is much smaller than the desktop screen, and it can be as big as 400px wide and sometimes much smaller. (some phones claim to have a bigger width, but it's a lie-or it can be said to provide us with useless information.) ）

The pixel middle tier in a tablet device bridges the gap between the desktop and mobile environments, such as the ipad or the legendary hp-based device developed by webos, but that doesn't change the underlying problem. Sites must also be able to work on mobile devices, so we have to allow them to display properly on small screen sizes.

The most important problem is the size of the css, especially the Viewport. If we copy the desktop environment mode, then our CSS will immediately stall (translator: that is, display chaos).

Let's take a look at width: 10% the example before sidebar. If the mobile browser wants to implement the same behavior as a desktop browser, they set a maximum width of 40px for the element, but this is too narrow. Your streaming layout will look Messy.

One way to solve this problem is to create a specific site for your mobile browser. Put aside whether you need to do this basic problem, and the actual situation is that only a few site owners really know to do special processing of mobile Devices.

Mobile browser vendors want to give their customers the best possible experience, which now means "as much as the desktop". So it is necessary to play some tricks.

Two X viewport

The viewport is too narrow to display your CSS layout properly. The obvious solution is to widen the Viewport. In any case, it needs to be divided into two parts: visual viewport and layout Viewport.

George Cummins the best explanation for the basic concepts on stack overflow:

Think of layout viewport as a big picture that doesn't change size or shape. Now imagine that you have a smaller frame, and you look at the big picture through it. (translator: can be understood as "glimpse") this small frame is surrounded by opaque material, which obscures all of your sight, leaving only part of the larger picture to You. The part of the larger image you can see through this frame is the visual Viewport. When you keep the frame (zoom Out) from looking at the whole picture, you can do it without a big picture, or you can look closer (zoom In) and see only the Parts. You can also change the direction of the frame, but the size and shape of the large map (layout viewport) will never Change.

Also look at the explanations Chris Gave.

Visual Viewport is the part of the page that is currently displayed on the Screen. The user can scroll to change the portion of the page he sees, or zoom to change the size of the visual Viewport.

In any case, the CSS layout, especially the percent width, is calculated using layout viewport as a frame of reference, which is thought to be wider than visual viewport.

So the element uses the width of the layout viewport in the initial case, and your CSS is interpreted on the assumption that the screen (the Translator's note: a virtual screen with width equal to the layout viewport) seems significantly wider than the phone screen width (physical screen). This makes your site layout behave the same as it does on a desktop browser.

How wide is the layout viewport? Each browser is not the Same. The Safari iphone is 980px,opera for 850px,android WebKit for 800px and last ie for 974px.

Some browsers have special behaviors:

• Symbian WebKit will keep layout viewport equal to visual viewport, yes, which means that owning a percentage-width element can be a strange behavior. however, If the page cannot be placed into visual viewport because it has an absolute width set, The browser stretches the layout viewport to a maximum width of 850px.
• Samsung WebKit (on Bada) makes the layout viewport as wide as the widest element.
• On blackberry, layout viewport equals visual viewport in the case of a 100% scale. It's not going to Change.

Scaling

It is clear that two viewport are measured in CSS Pixels. But when zooming in (if you zoom in and the CSS pixels on the screen get smaller), the dimensions of the visual viewport change, and the layout viewport is still the same size as Before. (if This is not the case, your page will often be re-layout as the percent width is recalculated.) ）

Understanding Layout Viewport

To understand the size of layout viewport, we have to look at what happens when the page is completely zoomed Out. Many mobile browsers will initially display any page in a fully scaled-down Mode.

The point is that the browser has chosen a size for its layout viewport, so that it completely overwrites the screen (and equals visual viewport) in the case of fully zoomed out Mode.

So the width and height of the layout viewport is equal to the size of any content that can be displayed on the screen in the minimized mode. These dimensions remain the same when the user zooms in.

Layout viewport width is always the Same. If you rotate your phone, visual viewport changes, but the browser fits the new orientation with a slight magnification, so the layout viewport is as wide as the visual Viewport.

This has an impact on the height of the layout viewport, which is now smaller than portrait mode (vertical screen). But web developers don't care about height, they only care about Width.

Metric Layout Viewport

We now have two viewport that need to be measured. fortunately, The browser war gives us two property Pairs.

document.documentElement.clientWidthAnd -Height contains the dimensions of the layout viewport.

Document.documentelement.clientwidth/height

• Meaning: Dimensions of Layout viewport
• Unit of measure: CSS pixels
• Full support for opera, iPhone, Android, Symbian, Bolt, microb, skyfire, obigo.
• There is a problem with visual viewport in Iris
  • Samsung WebKit <meta viewport> Returns the correct value when a label is applied to the page, otherwise the dimension of the element is Used.
  • Firefox returns the screen size in device Pixels.
  • IE returns 1024x768. however, It stores the information in document.body.clientWidth/Height . This is consistent with the IE6 of the Desktop.
  • The value of the NetFront is correct only in the case of a 100% scale.
  • Symbian WebKit 1 (old s60v3 Device) does not support these Properties.
• BlackBerry does not support.

Orientation has an effect on height, but not on Width.

Measure Visual Viewport

For visual viewport, It is window.innerWidth/Height measured by. Obviously when the user shrinks or zooms in, the dimensions of the measurements change, because the CSS pixels on the screen increase or decrease.

Window.innerwidth/height

• Meaning: the dimensions of the Visual Viewport.
• Unit of Measure: CSS Pixels.
• Fully supports IPHONE,SYMBIAN,BLACKBERRY.
• Problem
  • Opera and Firefox return the screen width in device pixels.
  • Android,bolt,microb and NetFront return layout viewport dimensions in CSS Pixels.
• IE is not supported, but it document.documentElement.offsetWidth/Height provides the dimensions of the visual viewport IN.
  • Samsung WebKit returns the size of layout viewport , depending on whether the page has a <meta viewport> label Applied.
• Iris,skyfire,obigo is simply Nonsense.

Unfortunately this is part of the browser incompatibility problem, and many browsers still have to add support for the visual viewport metric Dimension. But there is no browser to store this metric size in any other property pairs, so I guess window.innerWidth/Height it is the standard, although it is poorly supported.

Screen

Like a desktop environment, the screen.width/height screen size is provided in device Pixels. Like in a desktop environment, as a developer you never need this Information. You are not interested in the physical dimensions of the screen, but rather on how many CSS pixels are currently on the Screen.

Screen.width and Screen.height

• meaning: Screen Size
• Unit of measure: device pixel
• Full support for Opera mini,android,symbian,iris,firefox,microb,ie,blackberry.
• Issue: Opera Mobile on Windows Mobile offers only the dimensions of landscape mode (horizontal screen). The value returned by Opera Mobile on the S60 is Correct.
  • Samsung WebKit returns the size of layout viewport, depending on whether the label is applied on the page <meta viewport> .
  • iphone and Obigo only provide portrait mode (vertical screen) size.
  • NetFront only provides the dimensions of landscape mode (horizontal screen).
• The Bolt,skyfire is still on the Drag.

Scale Zoom zoom level

It is not possible to read the scale directly, but you can screen.width window.innerWidth get its value by dividing it. Of course this is only useful if the two attributes are perfectly supported.

fortunately, scaling is not too important. What you need to know is how many css pixels are on the current Screen. You can window.innerWidth get this information by getting it, if it is supported Correctly.

Scrolling distance scrolling offset

What you need to know is where the visual viewport is currently relative to layout viewport. This is the scrolling distance, and it is stored in the same way as on the desktop window.pageX/YOffset .

Window.pagex/yoffset

• Meaning: the scrolling distance is the same as the distance of visual viewport relative to layout viewport.
• Unit of measure: CSS pixels
• Fully supports IPHONE,ANDROID,SYMBIAN,IRIS,MICROB,SKYFIRE,OBIGO.
• Problem: Opera,bolt,firefox and NetFront always return 0.
  • Samsung WebKit <meta viewport> Returns the correct value only when it is applied to the Page.
• Ie,blackberry is not Supported. IE puts the value into existence document.documentElement.scrollLeft/Top .

\

As on the desktop, the document.documentElement.offsetWidth/Height entire size of the element in CSS pixels is provided .

Document.documentelement.offsetwidth/height

• Meaning: The overall size of the Element.
• Unit of Measure: CSS Pixels.
• Fully supports OPERA,IPHONE,ANDROID,SYMBIAN,SAMSUNG,IRIS,BOLT,FIREFOX,MICROB,SKYFIRE,BLACKBERRY,OBIGO.
• Problem: the value of NetFront is correct only if the 100% scale is Scaled.
  • IE uses this property pair to store the dimensions of the visual Viewport. In ie, go to document.body.clientWidth/Height get the correct Value.

Media Query Medium queries

Media queries work the same way as they do on a desktop Environment. width/heightuse layout viewport as a reference and measure with CSS pixels, device-width/height use the device screen, and measure in device Pixels.

In other words, it is the mirror of the value and the width/height document.documentElement.clientWidth/Height device-width/height screen.width/height Mirror of the Value. (they are actually doing this in all browsers, even if the value of the image is Incorrect.) ）

Media Enquiry

• Meaning: The width of the measure element (css Pixels) or the device width (device pixels).
• Fully supports OPERA,IPHONE,ANDROID,SYMBIAN,SAMSUNG,IRIS,BOLT,FIREFOX,MICROB.
• Skyfire,ie,blackberry,netfront,obigo is not Supported.
• Note What I'm testing here is whether the browser can get their data from the correct "property pair". These properties are not part of the test to provide the correct Information.

Which metric size is now more useful for web developers? My point is, I don't know.

I began to think device-width of the most important one because it gave us some information about the devices we might use. For example, You can change the width of your layout according to the width of the device. however, You can use <meta viewport> it to do this, and it device-width is not absolutely necessary to use media queries.

So width what is the more important media query? It may be that it provides some clues about the correct width that the browser manufacturer thinks the site should have on the Device. But it's a little blurry, and width media queries don't actually provide any other Information.

So I don't make a choice. At the moment, I think media queries are important in identifying whether you're using a desktop, tablet, or mobile device, but it's not useful to differentiate between tablets or mobile Devices.

Or there are other Uses.

Event coordinates

The event coordinates here are similar to how they work in a desktop Environment. unfortunately, only Symbian WebKit and Iris are the only two browsers that have been able to get three exactly the right values in 12 tested Browsers. All other browsers are more or less a serious problem.

pageX/Yis still relative to the page, in CSS pixels, and it is by far the most useful of the three property pairs, just as it does in the desktop Environment.

Event coordinates

• Meaning: See the text
• Unit of Measure: See body
• Full support Symbian,iris
• Problem: Opera Mobile provides pagex/y values in three property pairs, but it's a problem when you scroll a distance.
  • Clientx/y equals pagex/y on Iphone,firefox and Blackberry.
  • Screenx/y equals clientx/y on Android and MicroB (in other words, in CSS pixels).
  • It's wrong to screenx/y on Firefox.
  • Ie,blackberry and Obigo do not support pagex/y.
  • The values of the three property pairs on NetFront are equal to Screenx/y.
  • Clientx/y equals screenx/y on the Obigo.
  • Samsung WebKit has been returning to Pagex/y.
• Not tested on opera Mini,bolt,skyfire.

clientX/Yis relative to the visual viewport to calculate, in CSS Pixels. It makes sense, even if I don't fully point out the benefits of doing So.

screenX/Yis measured relative to the screen, in device Pixels. of course, This clientX/Y is the same as the frame of reference, and the device pixel is useless here. So we don't have to worry about it screenX/Y , just as useless in a desktop Environment.

Viewport META Tags

Meta Viewport

• Meaning: sets the width of the layout viewport.
• Unit of Measure: CSS Pixels.
• Full support for Opera mobile,iphone,android,iris,ie,blackberry,obigo.
• Opera Mini,symbian,bolt,firefox,microb,netfront is not Supported.
• Problem: Skyfire cannot process my test page.
  • If you apply to a page in Samsung WebKit <meta viewport> , the meaning of some other attributes Changes.
  • Opera Mobile,iphone,samsung and BlackBerry do not allow users to zoom Out.

finally, Let's talk about <meta name="viewport" content="width=320"> it, at first it was an extension of apple, but at the same time it was used by more Browsers. It means to adjust the size of the layout viewport. To understand why it is necessary to do so, let's take a step back.

Suppose you create a simple page, and you don't have a "width" set for your Element. Now they will be stretched to fill the layout viewport width of 100%. Most browsers zoom to show the entire layout viewport on the screen, producing the following effect:

All users will zoom in immediately, this is working, but most browsers remain intact to keep the width of the element, which makes the text difficult to Read.

(the notable exception is Android WebKit, which actually reduces the size of the elements that contain text, so the text fits the Screen.) This is just too good, I think all other browsers should learn this Behavior. I will write this issue in Full. ）

Now you should try to set html {width: 320px} . Now the elements have shrunk, and the other elements are now using 100% of the 320px. This is useful when the user zooms in, but it doesn't work in the initial state, and when the user faces a zoomed-out page, it doesn't contain any content.

To circumvent the problem, Apple invented the viewport meta Tag. When you set it <meta name="viewport" content="width=320"> , you set the layout viewport width to 320px. The initial state of the page is now also correct.

You can set the width of the layout viewport to any size you want, including device-width . The device-width screen.width value of (in device Pixels) is set, and the dimensions of layout viewport are reset Accordingly.

But Here's a Catch. Sometimes the formal is screen.width not so clear, because the number of pixels is too large. For example, the normal width of Nexus one is 480px, but Google's engineers feel that when used device-width , the width of layout viewport is 480px, which is a bit too big. They reduce the width to two-thirds, so they device-width will return you a 320px width, just like on the Iphone.

if, as the rumor suggests, the new iphone will show off a larger number of pixels (doesn't mean a bigger screen), I wouldn't be surprised if Apple had borrowed this Behavior. Maybe device-width it will mean 320px at the End.

Related research

Some of the related topics have to be further studied:

• position: fixed。 A fixed element, as we know, is positioned relative to the Viewport. But with respect to which viewport? I'm doing the research at the same time.

• Other media inquiries: Dpi,orientation,aspect-ratio. In particular, dpi, which is a disaster area, not only because all browsers return 96dpi, is usually wrong, but also because I am completely unsure which value is most interesting to web Developers.

• What happens when an element is wider than the layout viewport/html element? For example, do i width: 1500px insert an element with attributes into one of my test pages? This element will be stretched out from the HTML element ( overflow: visible ), but this means that the actual viewport can become wider than the layout viewport. In addition to this, the old Android (Nexus One) will magnify HTML elements when this happens. Is that a good idea?

CSS Viewport 2