Anatomy of viewports

In this mini-series of articles, I'll explain how the width of viewports and various important HTML tag elements work, such as the <html> tag. It will also explain the width of window and screen .

The first part is mainly about desktop ( pc ) browsers, and the basic purpose is to create a stage for the discussion of this topic on mobile ( mobile ) browsers. The vast majority of web developers already have an intuitive understanding of the concept of pc . mobile has the same concept, but is more complicated. As you know, a friendly warmup will greatly help you understand the mobile browser.

Concept: `pixels` for device and `CSS` for `pixels`

First of all you should understand the CSS of pixels and the difference between it and pixels of the device.

CSS pixels is an abstract unit mainly used in browsers to accurately measure the content on the Web page. In general, CSS pixels are called device-independent pixels ( device-independent pixel ), or DIPs for short. CSS pixels can be understood as the pixels written in the style file. When the user does not zoom the page, CSS pixels are equivalent to device independent pixels.
Device Independent Pixel Also known as Density Independent Pixel, can be thought of as a point in the computer coordinate system that represents a virtual pixel (say CSS pixel) that can be used by a program and then converted to a physical pixel by the associated system. For example, iPhone6 of 375px is a device-independent pixel, which is the physical width and screen size of the device screen.
physical pixel is also known as device pixel, which is one of the smallest physical components in a display device. Each pixel can set its own color and brightness according to the operating system. It's the tiny distance of these device pixels that tricks the image we see with the naked eye. The resolution we often say refers to physical pixels. For example, iPhone6 of 750px refers to physical pixels. The higher the physical pixels, the clearer the picture.

Let's assume the device's pixels is the correct (standard) width of pixels . These pixels determine the official resolution on those devices you work on. In most cases, the exact value can be retrieved from screen.width/height .

If the user zooms ( zoom ) the browser, of course the calculation must be changed. For example, if the user scales 200% , the appeal display can only accommodate 4 of the above elements horizontally.

Zoom on modern browsers, based on "stretch" pixels . As a result, the width on the html element is not changed from 128pix to 256px 200% but the real pixels is doubled. html element is still formally 128CSS of pixels , even though it occupies pixels of the 256 device. It means that scaling does not change the style width and height of the element, but makes it display at 256pix, and scaling does not change the physical pixel

In other words, scaling 200% one unit of CSS of pixels became 4 times of equipment pixels so big that width * 2, height * 2, area expanded 2 * 2.

The following picture will clearly explain this concept. As shown in 1-1 , there are 4 and 1 pixels, scaled to 100% elements of html , and CSS of pixels complete and device overlap pixels

When we zoom out the browser, CSS of pixels starts to shrink, causing 1 of pixels units to overlap with CSS of pixels , as shown in 1-2

Similarly, when zooming in on the browser, the opposite happens. CSS of pixels starts to expand, causing 06231a5f3797ba of 1 unit of CSS to overlap pixels of multiple devices, as pixels in Figure 1-3

Overall, you only need to focus on CSS of pixels , these pixels specify how your styles are rendered.

The device's pixels is pretty much useless to you. But not so for users. The user will zoom the page until he can read the content comfortably. But you don't need to care about these zoom levels. The browser will automatically ensure that your CSS pixels will be stretched or shrunk.

`100% zoom`

This example sets the zoom level to 100% . Now we define more rigorously, as follows:

At zoom level 100% , 06231a5f3798ce of CSS in 1 pixel is strictly equivalent to device pixel in 1 units

100% The concept of scaling is great for expressing what comes next, but you don't have to worry too much about it in your day-to-day work. On a desktop system, you would normally test your site at the 100% zoom level, but even if the user zooms, the magic of CSS of pixels will ensure that your site's appearance remains the same scale.

`Screen size Screen size`

`screen.width and screen.height`

Meaning: The full size of the user's screen.
Metric: pixels for the device.
Compatibility issue: IE8 , regardless of whether IE7 mode or IE8 mode is used, it is measured by CSS of pixels

Let's start with some special sizes: screen.width and screen.height . These two properties contain the full width and height of the user's screen. These dimensions are defined using the device's pixels , and their values do not change due to scaling: they are characteristic of the display, not the browser. As shown in Figure 1-4 .

Interesting, right? But what do we use it for?

Simply put, wood works! The user's monitor width doesn't matter to us - unless you want to use them for network statistics.

`Browser size Window size`

`window.innerWidth and window.innerHeight`

Meaning: contains full browser size of scrollbar size
Metric: CSS of pixels
Compatibility issue: IE is not supported, Opera is measured with device pixels

Instead, you want to know the internal dimensions of the browser. It defines how much area the current user can take up for your CSS layout. You can get it via window.innerWidth and window.innerHeight . Figure 1-5

Obviously, the inner width of the window uses CSS of pixels , you need to know how many of your own elements can fit into the browser window, and this amount will decrease as the user zooms in the browser ( the browser zooms in, window.innerWidth and window.innerHeight will smaller ) (Figure 1-6). Therefore, when the user enlarges the display, the available space of the browser window you can obtain will be reduced. window.innerWidth and window.innerHeight are the reduction ratios.

Opera browser is an oddball on this issue, and it's quite a bit when the user zooms in on the browser display. So when the user zooms in, you get less free space in the browser window. window.innerWidth and window.innerHeight do not decrease. On desktop browsers, this feature is annoying, but on mobile device browsers it's deadly, as we'll discuss later

Note that the size of the width and height inside the window includes the size of the scroll bar. (This is mainly for historical reasons)

`Roll shift Scrolling offset`

`window.pageXOffset and window.pageYOffset`

Meaning: Shift of the page
Metric: CSS of pixels
Compatibility issue: pageXOffset and pageYOffset are not supported in IE 8 and earlier versions of IE , use " document.body.scrollLeft " and " document.body.scrollTop " instead

window.pageXOffset and window.pageYOffset , define the horizontal and vertical displacement of the page ( document ) relative to the window origin. So you can locate how far the user scrolled the scrollbar distance . As 1-7

This property is also measured as CSS of pixels , same as the question above, you want to know how much scroll bar the user scrolls up when the user zooms in the window.

In principle, scrolls up the page when the user zooms in the browser, window.pageXOffset and window.pageYOffset will change . But when the user zooms in on the page, the browser will try to keep the elements of the page currently visible to the user still visible. Although this feature does not perform as expected, it means: in theory, window.pageXOffset and window.pageYOffset have not changed in this case, and CSS of pixels that was scrolled off the screen by the user is almost kept unchanged. As shown in 1-8 .

`Concept: Windows viewport`

Before we move on to discuss more features of JavaScript properties , let's introduce another concept: viewport .

viewport 's function is to control your site's highest block ( block ) container: <html> element.

Sounds a bit cryptic, for example~ Let's say you define a variable-size layout ( liquid layout ), and you define a sidebar with a width of width: 10% . This sidebar automatically expands and contracts when you resize the browser window. What is the principle of this?

Technically speaking, the principle is that the width of the sidebar is 10% of the width of its parent element, and we set its parent element to be

and you did not specify a width. So the question becomes what is the width of <body> ?

Usually, a block-level element occupies the width of 100% of the parent element (there are exceptions here, ignore it for the time being). So the width of <body> is the width of its parent element <html> .

So how wide is the <html> element? Because its width is exactly the width of the browser. So your sidebar width of width: 10% would take up the browser width of 10% . So all web developers intuitively know and use this feature. But you may not know how. In principle, the width of <html> is limited by viewport , and the <html> element is 100% of the width of viewport .

viewport , in turn, is strictly equal to the browser's window: that's what the definition is. viewport is not a concept of HTML , so you cannot modify it by CSS . It's the width and height of the browser window - on desktop browsers, it's a bit more complicated on mobile browsers.

`Impact Consequences`

Zoom events have some weird effects, you can experiment this site. When the page is scrolled to the top, and the browser is enlarged by 2-3 times, the width of the website will exceed the browser window. Scroll the page to the far right, and you will find that the blue column at the top of the website is no longer aligned. Figure 2-1

This effect reflects how viewport is defined. I defined the width of the top blue column to be width: 100% . What's 100% ? of course

The width is also the width of viewport , which is also the width of the browser window.

key point: is normal at scale 100% , now we zoom in the browser, viewport becomes smaller than the total width of the website. No effect on viewport , but the content of the page overflows the <html> element, but it has the attribute overflow: visible . It means that the overflowed part will still be displayed.

But the blue column does not overflow. I define its width as width: 100% , and the browser assigns it a width of viewport . The browser doesn't care if the width of the column is too narrow. As 2-2

`page width document width ?`

What I really want to know is the total size of the content of the page, including the part that extends beyond the browser window. So far, as far as I know there is no way to find this value (unless, of course, you calculate margin for the width of all parts of the page including all elements, but that calculation is prone to error).

I'm starting to believe that we need a JavaScript feature pair ( property pair ) to denote what I call a page width of document width (measured in terms of CSS of pixels , of course). As 2-3

If we're really feeling annoyed about this: why not expose these values in CSS ? I was expecting to define width: 100% to control the width of the blue column of the page, which is based on the width of the page and not the width of the element. This seems tricky ( This is bound to be tricky ), and I wouldn't be surprised if this is successfully implemented.

`Metric viewport Measuring the view port`

`document.documentElement.clientWidth and document.documentElement.clientHeight`

You may want to know the dimensions of viewport , they can be obtained by document.documentElement.clientWidth and document.documentElement.clientHeight . As 2-4

If you're familiar with DOM , you'll know that document.documentElement is actually the <html> element: the root element of the HTML document. However, viewport is a higher-level element than <html> , and metaphorically, it is the element that holds the <html> element. That would depend on whether you assign width to the element (I don't recommend it, but it works)

In that case document.documentElement.clientWidth and document.documentElement.clientHeight still give the dimensions of viewport , not the <html> element. (This is a special rule only for this particular element for this property pair. In all other cases the element uses the actual width.) Figure 2-5 . Assign 25% to the <html> element. However, the values of `document.documentElement.clientWidth and document.documentElement.clientHeight remain unchanged. Although it seems to take the value from the <html> element, the actual description is indeed the size of viewport .

so document.documentElement.clientWidth vs document.documentElement.clientHeight will only give the dimensions of viewport regardless of how the <html> element size changes.

`Two feature pairs two property pairs`

But isn't the size of viewport also described by window.innerWidth/Height ? Well, yes and no.

There is a strict distinction between these two features, almost nitpicking.

We can get these two feature pairs because they are leftovers from the browser wars. In the past, Netscape only supported window.innerWidth/Height , and IE only supported document.documentElement.clientWidth/Height . All other browsers have supported both features since then. But IE has not supported window.innerWidth/Height .

On desktop systems, having these two features is a minor annoyance, but on mobile devices it becomes a blessing. We will see later.

`Metric <html> Element measuring the <html> element`

`document.documentElement.offsetWidth/Height`

If clientWidth/Height has been used to indicate the size of viewport , how do we get the size of the <html> element? — document.documentElement.offsetWidth/Height . As 2-6

This feature actually allows you to access the block-level element <html> element, if you assign a width to the <html> element, offsetWidth will actually respond. As 2-7

`Event coordinates Event coordinates`

`pageX/Y, clientX/Y, screenX/Y`

As 2-8、2-9 and 2-10

9 is likely you will use pageX/Y and 1 will use clientX/Y , screenX/Y is basically useless.

`Media Query media queries`

`mediaqueries`

One last bit of text about the @media property of css . The starting point is simple: you can define special CSS rules based on a specific width of the page. for example.

div.sidebar {
  width: 300px;
}
@media all and (max-width: 400px) {
  // styles assigned when width is smaller than 400px;
  div.sidebar {
    width: 100px;
  }
}

If the width is greater than 400px , then the width of sidebar is 300px . Conversely, the width of sidebar is 100px

There are two related media queries: width/height and device-width/device-height . As 2-11

Which one should I use? A very brainless result: width . web does not need to be interested in the width of the device in the development, but width makes it calculated according to the size of the browser window

So use width and forget device-width in desktop browsers. Next we'll see a bit of clutter in mobile.

`Summarize`

This concludes a brief discussion of the characteristics of desktop browsers, with the second part focusing on mobile devices and their important differences from desktop browsers.

Next is the second part, which is derived from A tale of two viewports — part two .

`Problems with mobile browsers`

The width of the device is the biggest difference between mobile browsers and desktop browsers. Mobile devices typically display less content than desktop browsers display the same website. Either zooming the browser makes the text unreadable, or only showing parts of the site that fit the device.

Mobile devices have smaller screen widths than desktop browsers, often up to 400px wide, and often smaller. (Some phones claim to be wide, but they lie - or give us some useless information)

Some mid-width pad devices ( table device ) such as iPad or the legendary HP webOS devices fill the gap between desktop and mobile, but don't solve the underlying problem. Sites still had to work on mobile devices, and we had to make them perform well on small screens.

The storm center of the problem lies in CSS , specifically the size of viewport . If we just copied the desktop style to the mobile device, our CSS would crash ugly

(Assuming a width of 400px for mobile devices) We go back to the sidebar of width: 10% . If you do the same on a mobile device, it will show 40px wide, which is too narrow. Your variable layout looks horribly squashed.

One solution is to rebuild a special website for mobile devices. Even jumping off the basic questions: what are you going to do about it, the reality is that very few webmasters are ready to embrace the mobile-friendly changes.

Mobile device browser vendors expect their clients to provide the best possible experience, which now means "as much as a desktop browser can". Therefore many processing means are necessary.

`Two viewport`

So viewport too narrow to serve your basic CSS layout well. The most obvious solution is to make viewport wider. So this requirement is divided into 2 aspects: virtual viewport ( visual viewport ) and layout viewport ( layout viewport ).

George Cummins explains the basic concept at Stack Overflow , .

Imagine that layout viewport is a large image that cannot be changed in size or angle. Now you have a smaller box to view the big picture, the box is surrounded by opaque material, so you can only see part of the big picture. The part of the big picture you see through this box is called the dummy viewport ( visual viewport ). You can hold this frame away from the big picture (the user's zoom out function) to see the big picture all at once. Or you can stand close (user's zoom in page feature) to see part of it. You can change the orientation of the box, but the size and shape of the large image will not change.

You can see for details by Chris.

visual viewport is the partial page currently displayed on the screen. The user scrolls the page to change the visible portion, or zooms the browser to change the size of visual viewport . See Figure 1-1.

But the CSS layout, especially the perceptual width ( percentual widths ) is usually defined in terms of layout viewport , which is much wider than visualviewport .

However, the width of the <html> element is inherited from layout viewport , and your CSS should be prepared in advance for the screen ( layout viewport ) that needs to be processed is not much larger than the width of the phone screen. This is used to ensure that your website looks and behaves exactly like it does on a desktop browser.

How wide is layout viewport ? Every browser is different. iPhone on Safari uses 980px , Opera 850px , Android's Webkit core 800px , IE 974px .

Some browsers have special features:

Saipan webkit tries to save the same width as layout viewport and visual viewport . As a result, elements that define percentage widths can become hugely ugly. Of course, if the page has a specific width other than the one that fits visual viewport , then the maximum value of that width will be set to 850px
Samsung's WebKit ( bada ) will set layout viewport as wide as the widest element
On the BlackBerry layout viewport and visual viewport are the same width when scaled at 100% .

`Zoom Zooming`

Both viewports are measured as CSS of pixels . When you change visual viewport by scaling, layout viewport remains unchanged.

`Understanding layout viewport`

To understand the dimensions of layout viewport , let's first look at what happens when the page is completely shrunk. Many mobile device browsers open websites in minimal zoom mode when they are initially opened by default. (i.e. showing the full width of the page on the phone screen) . As shown in 1-2 .

Highlights : Browsers have chosen their layout viewport size, which completely covers the screen of mobile browsers in minimum zoom mode.

At this time, the width and height of layout viewport are the same as the width and height of the content that can be displayed on the page in the minimum zoom mode. It remains the same even if the user zooms in and out. As 1-3

layout viewport width is usually preserved unchanged. If you rotate your phone, visual viewport changes, but the browser scales the page to fit so that layout viewport is again the same width as visual viewport . As shown in 1-4 .

This affects the height of layout viewport , which suddenly becomes smaller than in portrait mode ( portrait model portrait mode), but the web developers don't care about height, only width. Figure 1-5.

`Metric layout viewport`

`Dimensions of document.documentElement.clientWidth/Height`

Meaning: layout viewport size
Metric: CSS of pixels
Full support: Opera, iPhone, Android, Symbian, Bolt, MicroB, Skyfire, Obigo
Problem: On Iris it visual vieport
- Samsung's Webkit core browser is only correctly represented when the <meta viewport> tag is written on the page. Otherwise it means
- FireFox is measured in pixels of the device
- IE returns 1024px 768px while the exact dimensions are saved in document.body.clientWidth/Height
- NetFront is only correct when 100% is scaled
- Saipan's Webkit1 (on the S60v3 device) does not support these properties
Not supported: Blackberry

Luckily browsers left us with 2 feature pairs due to the browser wars to measure both viewport .

document.documentElement.clientWidth/Height passes the size of layout viewport , as shown in 1-6

Rotation only concerns height, not width. Figure 1-7

`Metric visual viewport`

`window.innerWidth/Height`

Meaning: visual viewport size
Metric: CSS of pixels
Full support: iPhone, Symbian, BlackBerry
question:
- FireFox and Opera return this value as the device's pixels
- Android, Bolt, MicroB, and NetFront return the value as CSS of pixels and the value of layout viewport
not support:
- IE , which uses document.documentElement.offsetWidh/Height to represent
- Samsung's Webkit core browser, which is only correctly represented when the <meta viewport> tag is written on the page. Otherwise it represents the size of <html>
Confusion: Iris, Skyfire, Obigo returns incomprehensible value

We use window.innerWidth/Height to measure visualvviewport . Obviously, as the user zooms the browser, this value changes, and more and less of CSS pixels on the screen. Figure 1-8

Unfortunately this is a work in progress and many browsers still do not support the metric visual viewport . As of now, no browsers store this metric elsewhere, and I'm guessing window.innerWidth/Height will become the standard, with albeit being the strongest proponent.

`screen Screen`

`screen.width and screen.height`

Meaning: screen size
Metric: pixels for device
Full support: Opera Mini, Android, Symbian, Iris, Firefox, MicroB, IE, BlackBerry
question:
- Opera gives only horizontal dimensions ( landscape size ) under Windows Mobile . Works correctly on S60 .
- Samsung's Webkit core browser, which is only correctly represented when the <meta viewport> tag is written on the page. Otherwise it represents the size of <html>
- iPhone and Obigo give vertical dimensions only ( portrait sizes )
- Android, Bolt, MicroB , and NetFront return the value as CSS of pixels and the value of layout viewport
not support:
- IE , which is represented using document.documentElement.offsetWidh/Height - Samsung's Webkit core browser, which is only correctly represented when the <meta viewport> tag is written on the page. Otherwise it represents the size of <html>
Confusion: Iris, Skyfire, Obigo returns incomprehensible value

Like the pc browser, screen.width/height indicates the size of the device's screen, measured in the device's pixels . As with pc browser, you will never need this information as a web developer. You don't care about the physical width of the screen, but about how much CSS of pixels is currently available to you.

`Zoom level Zoom level`

The zoom level cannot be obtained directly, but it can be calculated by dividing screen.width by window.innerWidth . Of course, it can only be used if these two features are perfectly supported.

Fortunately, the zoom level doesn't matter. You just need to know how many CSS of pixels are currently available for you. You can get this information from window.innerWidth - if your current browser supports it.

`Roll displacement scrolling offset`

`window.pageX/YOffset`

Meaning: see description
Metric: CSS of pixels
Full support: iPhone, Android, Symbian, Iris, MicroB, Skyfire, Obigo
question:
- Opera, Bolt, Firefox, and NetFront always returns 0.
- Samsung's Webkit core browser, which is only correctly represented when the tag is written on the page.
Not supported: IE , which uses document. scrollLeft/Top to represent

You agree that you need to know the current distance of visual viewport relative to layout viewport . This is the scroll offset, as in desktop browsers, stored using window.pageX/YOffset . Figure 1-9

`<html> element`

`document.documentElement.offsetWidth / Height`

Meaning: html The overall size of the element
Metric: CSS of pixels
Full support: Opera, iPhone, Android, Symbian, Samsung, Iris, Bolt, Firefox, MicroB, Skyfire, BlackBerry, Obigo
question:
- NetFront only returns the correct value when scaled by 100% .
- IE , use this feature pair to represent the size of visual viewport . It uses document.body. clientWidth/Height to denote

As on desktop systems, document.documentElement.offsetWidth/Height gives the element's size in terms of CSS of pixels . Figure 1-10

`Media query media queries`

`Mediaqueries`

Meaning: Measure <html> element in CSS of pixels or measure device in pixels of device
Full support: Opera, iPhone, Android, Symbian, Samsung, Iris, Bolt, Firefox, MicroB.
Not supported: Skyfire, IE, BlackBerry, NetFront, Obigo
Note: I've only tested that the browser is pulling these values from the correct feature pair. Whether the value in the feature pair is correct is not tested in detail here.

media queries as desktop systems. width/height uses pixels measured in CSS of layout viewport，device-width/height uses the device screen ( device screen ) measured in pixels of the device.

In other words, width/height reflects the value of document.documentElement.clientWidth/Height , and device-width/height reflects the value of screen.width/height . (All browsers follow the same principle, even if the value is wrong). As shown in 1-11 .

Which metric is more useful to web developers? I do not know either.

I initially thought device-width was more important because it gave information about the device that we might be able to use. For example, you can change the appearance of your website based on the width of the device. But you can also do this with the <meta viewport> tag. So using device-width not necessary.

So is width more useful? maybe. The makers of the browsers think they give some specifics about the widths that are useful for websites. But these are vague (confused), so width media query doesn't really give the rest of the information.

So I didn't make a decision. Now I think media query is important in identifying whether a website is in a desktop browser, pad browser, or mobile browser, and not useful in distinguishing between different pad and mobile devices.

`Event coordinates Event coordinates`

`Eventcoordinates`

Meaning: see below
Metrics: see below
Full support: Symbian, Iris
question:
- Opera is only pageX/Y , but this value will be wrong when scrolling the page too far.
- clientX/Y and pageX/Y are equal on iPhone, Firefox, and BlackBerry
- In Android and MicroB screenX/Y and clientX/Y are equal, that is, they measure the screen size with CSS of pixels
- Incorrect value of FireFox in screenX/Y
- IE, BlackBerry, and Obigo do not support pageX/Y.
- NetFront so all three values are screenX/Y .
- Obigo clientX/Y is screenX/Y .
- Samsung WebKit always returns pageX/Y .
Untested: Opera Mini,Bolt,Skyfire

Event coordinates are more or less supported on desktop browsers. Unfortunately, only Symbian `WebKit and Iris` of the 12 major browsers tested on mobile devices fully support these 3 coordinate features. The rest of the browsers have more or less problems.

pageX/Y , this feature is still based on the value of the page's CSS pixels metric, as shown in the desktop browser, it is the most useful of the three features. Figure 1-12

clientX/Y is based on visual viewport , and is measured in CSSpixels . This is more reliable, although I am not sure about the benefits of this calculation.

screenX/Y based on the value of the device's screen measured in pixels of the device. Apparently it uses the same reference as clientX/Y , and the device's pixels is useless. So we don't need to care about screenX/Y , as in desktop browsers, every bit is useless. Figure 1-13.

`viewport label meta viewport of meta`

`Meta viewport`

Meaning: sets the width of layout viewport to
Metric: CSS of pixels
Full support: Opera Mobile, iPhone, Android, Iris, IE, BlackBerry, Obigo
Not supported: Opera Mini, Symbian, Bolt, Firefox, MicroB, NetFront
question:
- Skyfire cannot process my test page.
- Under Samsung's wibkit browser, the values appear to change some feature pairs.
- Opera Mobile, iPhone, Samsung, and BlackBerry does not allow users to perform minification after setting viewport ( do not allow the user to zoom out .)

Finally we discuss <meta name="viewport" content="width=320"> ; originally this is a Apple extension tag of html , but it is reused by many browsers to set the width of layout viewport . To understand what it means, let's step back and look at the basics.

Suppose you create a page and don't assign width to it. Then it stretches out to take the width of 100% of viewlayout . Most browsers shrink the page to display this layout viewport on one screen width. We obtain the following effect. Figure 2-1.

For example, when opening the Baidu page on the PC side, the page does not have Meta viewport set, because the screen of the mobile device is generally much smaller than that of PC , the webkit browser will map a larger "virtual" window to the screen of the mobile device, the default virtual The window is 980 pixels wide (the standard width for most websites today), and then scaled by a certain ratio ( 3:1 or 2:1 ). That is to say, when we load a normal web page, webkit will first load the web page with the browser standard of 980 pixels, and then reduce it. Note that this reduction is a global reduction , that is, all elements on the page will be reduced and reduced. This page is displayed at the width of one screen

The user will immediately zoom in on the page. Although it will have an effect, most browsers will save the full width of the element (keep the element positioning unchanged), resulting in difficulty in reading (the text exceeds the screen), as shown in Figure 2-2

For example, in the above example, after the page is enlarged, the content will exceed the screen

(The only difference is the Android core browser under Webkit , which html elements with long strings of text to make them fit on the screen. This is genius, and I think all other browsers should reuse this feature. I will write more about this in the future)

Now you can try setting htm{width: 320px} . Now <html> element shrinks, and then all accounting elements occupy the 100% width of <html> : 320px . This works fine when the user zooms in on the browser display, but at the initial load zoomed out, the user feels bad because the page has almost no content. As shown in 2-3 .

To solve this problem, Apple introduced meta viewport . When you set <meta name="viewport" content="width=320"> , your site's layout viewport becomes 320px . The initial state of the page is correct. As 2-4

You can arbitrarily set the width of layoutwidth , even device-width . device-width is set by measuring screen.width with the device's pixels measure.

There is a hook here ( There’s a catch here ). Sometimes the strict screen.width doesn't make sense at all because the value of pixels is too large. For example, the strict width on Nexus One is 480px , but the engineers of Google felt that setting layout viewport to 480 was too large when the user set device-width . They cut 2/3 and provided 320px , which is the same as iPhone .

If, as rumored, the new iPhone will provide a huge pixel value (not equal to a huge screen, just the resolution), I wouldn't be surprised if they stick with this feature: device-width is 320 . Maybe eventually device-width will simply mean 320px .

`Summarize`

Why does set layout viewport to ideal viewport ? example, the ideal width of iPhone6 for ideal viewport is 375px . If meta viewport is not set, the page will be drawn with 980px or 800px of layout viewport by default, and then zoomed out to one screen display, making the element display very small and affecting the user's preview. If meta viewport is set, but layout viewport is not a device-independent pixel, the page will draw the layout with the set layout viewport , without scaling, and the displayed page size will exceed the visual viewport, so that scroll bars appear. If you can set layout viewport as device independent pixels, the visual viewport is equal to the layout viewport, and 1px of css pixels is equal to 1px of physical independent pixels. When using 750px high fidelity for adaptation, the root element font-size=viewport width * coefficient, for example, the coefficient is equal to 100/750, 750px is divided into 100px, each part is 1vw

`Related research`

Many related studies will be carried out in the future:

position: fixed . A fixed-position element, as we know, is positioned at viewport . But which viewport is it? My findings are as follows: .
The rest of media queries: dpi, orientation , especially dpi is a catastrophic region, not only because all browsers return 96dpi (usually this value is wrong), but because we don't know exactly which part of the web developer is interested in. a related issue )
What happens when our element is bigger than layout viewport or <html> ? If we insert a 1500px element in the page where layout viewport is 320px , it will exceed if we set overflow: visible for <html> . Does it mean that the actual viewport can be wider than the layout viewport ? Also, this happens when an old Android device ( Nexus One ) expands HTML element. Is this a good idea?

Concept: pixels for device and CSS for pixels

100% zoom

Screen size Screen size

screen.width and screen.height

Browser size Window size

window.innerWidth and window.innerHeight

Roll shift Scrolling offset

window.pageXOffset and window.pageYOffset

Concept: Windows viewport

Impact Consequences

Problems with mobile browsers

Two viewport

Zoom Zooming

Understanding layout viewport

Metric layout viewport

Dimensions of document.documentElement.clientWidth/Height

Metric visual viewport

window.innerWidth/Height

screen Screen

screen.width and screen.height

Zoom level Zoom level

Roll displacement scrolling offset

window.pageX/YOffset

<html> element

document.documentElement.offsetWidth / Height

Media query media queries

Mediaqueries

Event coordinates Event coordinates

Eventcoordinates

viewport label meta viewport of meta

Meta viewport

Summarize

Related research

记得要微笑

引用和评论

如何使用 webpack 优化 lodash

Concept: `pixels` for device and `CSS` for `pixels`

`100% zoom`

`Screen size Screen size`

`screen.width and screen.height`

`Browser size Window size`

`window.innerWidth and window.innerHeight`

`Roll shift Scrolling offset`

`window.pageXOffset and window.pageYOffset`

`Concept: Windows viewport`

`Impact Consequences`

`Problems with mobile browsers`

`Two viewport`

`Zoom Zooming`

`Understanding layout viewport`

`Metric layout viewport`

`Dimensions of document.documentElement.clientWidth/Height`

`Metric visual viewport`

`window.innerWidth/Height`

`screen Screen`

`screen.width and screen.height`

`Zoom level Zoom level`

`Roll displacement scrolling offset`

`window.pageX/YOffset`

`<html> element`

`document.documentElement.offsetWidth / Height`

`Media query media queries`

`Mediaqueries`

`Event coordinates Event coordinates`

`Eventcoordinates`

`viewport label meta viewport of meta`

`Meta viewport`

`Summarize`

`Related research`

`引用和评论`