HTML-HTML5+CSS3 authoritative guide Reading (V, the concept of device pixels and css pixels)

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

This article is about desktop browsers, and its sole purpose is to pave the way for similar discussions in mobile browsers. Most developers intuitively understand the concept of most desktop browsers. On the mobile side we will be exposed to the same concept, but it will be more complex, so a pre-discussion of the terminology you already know will be of great help to your understanding of mobile browsers.

Concept: device pixels and css pixels

The first concept you need to understand is the CSS pixel, and the difference between it and the device pixel.

Device pixels are pixels that we intuitively feel "reliable". These pixels provide a normal resolution for the various devices you use, and their values can be read from the attribute (typically) screen.width/height .

If you give an element a set width: 128px of properties, and your monitor is 1024px wide, when you maximize your browser screen, this element will be repeated on your display 8 times (presumably so; let's ignore those subtle places first).

If the user zooms in, the calculation will change. If the user is zoomed in to 200%, then the width: 128px element that owns the attribute will be displayed only 4 times on the 1024px wide display.

The way zooming is implemented in modern browsers is no wonder that "stretched" pixels. Therefore, the width of the element is not changed from 128 to 256 pixels, whereas the actual pixel is magnified twice times. Formally, the element is still 128 css pixels wide, even though it occupies 256 pixels of the device space.

In other words, zooming in to 200% makes a CSS pixel four times times as much as a device pixel. (width twice times, height twice times, total 4 times times)

Some pictures can explain the concept clearly. Here are four elements of the 100% scale ratio. There is nothing to see here; CSS pixels are completely overlapping with device pixels.

Now let's zoom out. CSS pixels start shrinking, which means that a device pixel now overlays multiple css pixels.

If you zoom in, the opposite behavior will occur. CSS pixels are starting to grow larger, and now a CSS pixel overlays multiple device pixels.

The point here is that you are only interested in CSS pixels. These are the pixels that control how your style sheet is rendered.

Device pixels are basically useless to you (the translator: referring to the developer). But the user will zoom in or out of the page until he can read it comfortably. In any case, the zoom level will not affect you. The browser will automatically make your CSS layout stretched or compressed.

100% Scaling

I started this example with the assumption that the zoom level is 100%. It's time to define this 100% more rigorously:

In the case of scaling level 100%, a CSS pixel is exactly equal to one device pixel.

The concept of 100% scaling is useful in the next explanation, but you don't have to worry too much about it in your daily work. In a desktop environment you will be testing your site with 100% zoom levels, but even if the user zooms in or out, the magic of the CSS pixel will ensure that your layout remains the same ratio.

Screen size

Screen.width/height

• Meaning: The overall size of the user's screen.
• Unit of measure: device pixels.
• Browser error: IE8 is measured in css pixels, and IE7 and IE8 modes have this problem.

Let's look at some useful metrics. We will start with screen.width and screen.height do. They include the entire width and height of the user's screen. Their dimensions are measured in device pixels because they never change: they are the properties of the display, not the browser.

fun! But what does this information have to do with us?

Basically useless. The user's display size is not important to us-well, unless you want to measure it to enrich your Web statistics database.

Window size

Window.innerwidth/height

• Meaning: The overall size of the browser window, including the scroll bar.
• Unit of measure: CSS pixels.
• Browser error: IE7 not supported. Opera is measured in device pixels.

Instead, you want to know the internal dimensions of the browser window. It tells you how much space a user has to make a CSS layout. You can window.innerWidth window.innerHeight get these sizes through and.

Obviously, the internal width of the window is measured in CSS pixels. You need to know how much of your layout space you can squeeze into your browser window, and this value will be reduced when the user zooms in. So if the user zooms in, you'll get less space in the window and window.innerWidth/Height the value will be smaller. (The exception here is opera, which is not reduced when users zoom in window.innerWidth/Height : They are measured in device pixels.) This problem is annoying on the desktop, but as we will see, this is very serious on mobile devices. ）

Note that the width and height of the measure are included in the scroll bar. They are also considered part of the internal window. (This is largely due to historical reasons.) ）

Scrolling distance

Window.pagex/yoffset

• Meaning: The distance the page scrolls.
• Metric: CSS pixels.
• Browser error: None.

window.pageXOffsetAnd window.pageYOffset that contains the scrolling distance of the document in both horizontal and vertical directions. So you can know how much distance the user has scrolled.

These properties are also measured in CSS pixels. What you want to know is how long the document has been scrolled, whether it's zoomed in or out.

Theoretically, if the user scrolls up and then zooms in, window.pageX/YOffset the change will occur. However, in order to maintain the consistency of the Web page, the browser will keep the same elements at the top of the visible page when the user zooms in. This mechanism does not always perform perfectly, but it does mean that there is no real change in the actual situation window.pageX/YOffset : The number of CSS pixels that are scrolled out of the window is still (presumably) the same.

Concept: Viewport

Before we continue to introduce more JavaScript properties, we must introduce another concept: viewport.

Viewport's function is to constrain the top-level of your site with block elements (containing block) .

This sounds a little blurry, so look at a practical example. Suppose you have a streaming layout, and one of your many sidebars has width: 10% attributes. The sidebar now zooms in and out as the browser window resizes. But how does this work?

Technically, what happens is that the sidebar gets 10% of the width of its parent element. Let's say it's an <body> element (and you haven't set it up yet 宽度 ). So the question becomes, <body> which is the width?

In general, all block-level elements use 100% of their parent element's width (there are some exceptions here, but let's ignore it now). So <body> the element is as wide as its parent element.

So what is the width of the element? Its width is the same as the width of the browser window. That's why your width: 10% property-owning sidebar will occupy 10% of the entire browser window. All Web developers are intuitively aware of and are using it.

What you may not know is how this behavior works in theory. Theoretically, the width of the element is limited by the width of the viewport. the element uses 100% of the viewport width.

Viewport, then, is actually equal to the browser window: it is so defined. Viewport is not an HTML structure, so you can't use CSS to change it. It only has the width and height of the browser window in the desktop environment. It can be complicated in a mobile environment.

Consequence consequences

This situation will have some strange consequences. You can see one of these consequences on this site. Scroll to the top, then zoom in two or three times, and then the content of the site overflows from the browser window.

Now scroll to the right, and you'll see the blue Sidebar at the top of the site no longer covers a whole line.

This behavior is a consequence of the way the viewport is defined. I set up the blue sidebar before the top width: 100% . What's 100%? element of 100%, its width and viewport are the same, viewport width is the same as the browser window.

The problem is that this works fine with 100% scaling, and now that we have zoomed in, viewport becomes smaller than the overall width of my site. This has no effect on viewport itself, the content is now overflowed from the element, but the element is owned overflow: visible , which means that the overflow content will be displayed in any case.

But the blue sidebar is not overflowing. I set it up before width: 100% , and the browser assigns the width of the viewport to it. They don't care if the width is too narrow now.

Document width?

What I really need to know is what the width of all the content in the page is, including the "sticking Out" section. As far as I know, it's impossible to get this value (well, unless you're going to calculate the width and margin of all the elements on the page, it's easy to say, in a tactful way).

I'm starting to believe that we need a JavaScript property pair that I call "document width" (which is obviously measured in css pixels).

And if we are really so fashionable, why not introduce this value into CSS? I will give my Blue sidebar, which is based on the width of the width: 100% document, not the width of the element. (But it's complicated, and I wouldn't be surprised if it didn't happen.) ）

Browser vendors, what do you think?

Metric viewport

Document.documentelement.clientwidth/height

• Meaning: Viewport size.
• Metric: CSS pixels.
• Browser error: None.

You may want to know the size of the viewport. They can be passed document.documentElement.clientWidth and -Height obtained.

If you understand the DOM, you should know that document.documentElement it actually refers to the element: that is, the root element of any HTML document. It can be said that viewport is a higher level than it is, it is the element that contains the element. If you set properties for width an element, this will have an impact. (I don't recommend it, but that's doable.) ）

In that case document.documentElement.clientWidth and -Height given is still the size of the viewport, not the element. (This is a special rule that only works on this attribute of the element.) In any other case, the actual width of the element is used. ）

So document.documentElement.clientWidth and -Height always represent the size of the viewport, regardless of the size of the element.

Two attribute pairs

But can the size of the viewport width also be window.innerWidth/Height provided? How to say, ambiguous.

There is a formal difference between the two attribute pairs: document.documentElement.clientWidth and -Height does not contain scroll bars, but window.innerWidth/Height contains. It's like a nitpick.

In fact, the existence of two attribute pairs is the product of browser warfare. At that time Netscape only supported window.innerWidth/Height , IE only supported document.documentElement.clientWidth and Height . Since then all other browsers clientWidth/Height have started to support, but IE is not supported window.innerWidth/Height .

Having two properties on a desktop environment is a bit cumbersome-but as we will see, on the mobile side this will be blessed.

Metrics

Document.documentelement.offsetwidth/height

• Meaning: The dimensions of the element (that is, the page).
• Metric: CSS pixels.
• Browser error: IE measures viewport, not elements.

So clientWidth/Height in all cases the size of the viewport is provided. But where do we go to get the dimensions of the elements themselves? They are stored in document.documentElement.offsetWidth and -Height among.

These properties allow you to access the element as a block-level element, and if you set width offsetWidth it, it will be represented.

Coordinates in an event

pagex/y, clientx/y, screenx/y

• Meaning: See the text.
• Unit of measure: see Body.
• Browser error: IE does not support pagex/y. IE and opera calculate screenx/y in css pixels.

Then the coordinates in the event. When a mouse event occurs, there are not less than five property pairs that can provide you with information about the location of the event. For our current discussion, three of them are important:

• pageX/YProvides coordinates that are measured in css pixels relative to the element.

• clientX/YProvides coordinates that are measured in CSS pixels relative to viewport.

• screenX/YProvides coordinates that are measured in device pixels relative to the screen.

90% of the time you will use pageX/Y ; usually what you want to know is the event coordinates relative to the document. The other 10% times you will be using clientX/Y . You never need to know the coordinates of the event relative to the screen.

Media Enquiry

Media Enquiry

• Meaning: See the text.
• Unit of measure: see Body.
• Browser error: IE does not support them.
  • If device-width/height it is measured in css pixels, then Firefox will use screen.width/height the value.
  • If width/height measured in device pixels, then safari and Chrome will use documentElement.clientWidth/Height the values.

Finally, talk about the media query. The principle is simple: you can declare a special CSS rule that is only executed when the page width is greater than, equal to, or less than a specific size. Like what:

{    width: 300px;}  {    //styles assigned when width is smaller than 400px;    Div.sidebar {        width: 100px;    }  }

The current sidebar is 300px wide, except when the width is less than 400px, in which case the sidebar becomes 100px wide.

The question is clearly: which width are we measuring here?

Here are two corresponding media queries: width/height and device-width/device-height .

1. width/heightUse documentElement .clientWidth/Height the same values as (in other words, viewport). It is working under CSS pixels.
2. device-width/device-heightUse screen.width/height the same values as (in other words, the width of the screen). It works under the device pixel.

Which one should you use? You want to do that? Of course it is width . The web Developer is not interested in the width of the device, which is the width of the browser window.

So use it in the desktop environment width and forget device-width it. We are about to see this situation more cumbersome on the mobile side.

Summarize

This article summarizes our search for the behavior of desktop browsers. The second part of the series points these concepts to the mobile side and shows some important differences from the desktop environment.

Transferred from: http://blog.jobbole.com/44319/

HTML-HTML5+CSS3 authoritative guide Reading (V, the concept of device pixels and css pixels)