0
팔로우
1 팔로워

A tale of two viewports — part one

In this mini-series I will explain how viewports and the widths of various important elements work, such as the element, as well as the window and the screen.

This page is about the desktop browsers, and its sole purpose is to set the stage for a similar discussion of the mobile browsers. Most web developers will already intuitively understand most desktop concepts. On mobile we’ll find the same concepts, but more complicated, and a prior discussion on terms everybody already knows will greatly help your understanding of the mobile browsers.

Concept: device pixels and CSS pixels

The first concept you need to understand is CSS pixels, and the difference with device pixels.

Device pixels are the kind of pixels we intuitively assume to be “right.” These pixels give the formal resolution of whichever device you’re working on, and can (in general) be read out from screen.width/height.

If you give a certain element a width: 128px, and your monitor is 1024px wide, and you maximise your browser screen, the element would fit on your monitor eight times (roughly; let’s ignore the tricky bits for now).

If the user zooms, however, this calculation is going to change. If the user zooms to 200%, your element with width: 128px will fit only four times on his 1024px wide monitor.

Zooming as implemented in modern browsers consists of nothing more than “stretching up” pixels. That is, the width of the element is not changed from 128 to 256 pixels; instead the _actual pixels_ are doubled in size. Formally, the element still has a width of 128 CSS pixels, even though it happens to take the space of 256 device pixels.

In other words, zooming to 200% makes one CSS pixel grow to four times the size of one device pixels. (Two times the width, two times the height, yields four times in total).

A few images will clarify the concept. Here are four pixels on 100% zoom level. Nothing much to see here; CSS pixels fully overlap with device pixels.

image description

Now let’s zoom out. The CSS pixels start to shrink, meaning that one device pixel now overlaps several CSS pixels.

image description

If you zoom in, the opposite happens. The CSS pixels start to grow, and now one CSS pixels overlaps several device pixels.

image description

The point here is that _you are only interested in CSS pixels_. It’s those pixels that dictate how your style sheet is rendered.

Device pixels are almost entirely useless to you. Not to the user; the user will zoom the page in or out until he can comfortably read it. However, that zooming level doesn’t matter to you. The browser will automatically make sure that your CSS layout is stretched up or squeezed in.

100% zoom

I started the example by assuming a zoom level of 100%. It’s time to define that slightly more strictly:

At zoom level 100% one CSS pixel is exactly equal to one device pixel.

The concept of 100% zoom is very useful in the explanations that are going to follow, but you shouldn’t overly worry about it in your daily work. On desktop you will generally test your sites in 100% zoom, but even if the user zooms in or out the magic of CSS pixels will make sure that your layout retains the same ratios.

Screen size

screen.width/height

Meaning Total size of the user’s screen. Measured in Device pixels Browser errors IE8 measures it in CSS pixels, in both IE7 and IE8 mode.

Let’s take a look at some practical measurements. We’ll start with screen.width and screen.height. They contain the total width and height of the user’s screen. These dimensions are measured in device pixels because they never change: they’re a feature of the monitor, and not of the browser.

image description

Fun! But what do we do with this information?

Basically, nothing. The user’s monitor size is unimportant to us — well, unless you want to measure it for use in a web statistics database.

Window size

window.innerWidth/Height

Meaning Total size of the browser window, including scrollbars. Measured in CSS pixels Browser errors Not supported by IE. Opera measures it in device pixels.

Instead, what you want to know is the inner dimensions of the browser window. That tells you exactly how much space the user currently has available for your CSS layout. You can find these dimensions in window.innerWidth and window.innerHeight.

image description

Obviously, the inner width of the window is measured in CSS pixels. You need to know how much of your layout you can squeeze into the browser window, and that amount decreases as the user zooms in. So if the user zooms in you get less available space in the window, and window.innerWidth/Height reflect that by decreasing.

(The exception here is Opera, where window.innerWidth/Height do not decrease when the user zooms in: they’re measured in device pixels. This is annoying on desktop, but fatal on mobile, as we’ll see later.)

image description

Note that the measured widths and heights include the scrollbars. They, too, are considered part of the inner window. (This is mostly for historical reasons.)

Scrolling offset

window.pageX/YOffset

Meaning Scrolling offset of the page. Measured in CSS pixels Browser errors None

window.pageXOffset and window.pageYOffset, contain the horizontal and vertical scrolling offsets of the document. Thus you can find out how much the user has scrolled.

image description

These properties are measured in CSS pixels, too. You want to know how much of the document has already been scrolled up, whatever zoom state it’s in.

In theory, if the user scrolls up and then zooms in, window.pageX/YOffset will change. However, the browsers try to keep web pages consistent by keeping the same element at the top of the visible page when the user zooms. That doesn’t always work perfectly, but it means that in practice window.pageX/YOffset doesn’t really change: the number of CSS pixels that have been scrolled out of the window remains (roughly) the same.

image description

Concept: the viewport

Before we continue with more JavaScript properties we have to introduce another concept: the viewport.

The function of the viewport is to constrain the element , which is the uppermost containing block of your site.

That may sound a bit vague, so here’s a practical example. Suppose you have a liquid layout and one of your sidebars has width: 10%. Now the sidebar neatly grows and shrinks as you resize the browser window. But exactly how does that work?

Technically, what happens is that the sidebar gets 10% of the width of its parent. Let’s say that’s the (and that you haven’t given it a `width`). So the question becomes which width the has.

Normally, all block-level elements take 100% of the width of their parent (there are exceptions, but let’s ignore them for now). So the `is as wide as its parent, theelement` .

And how wide is the element ? Why, it’s as wide as the browser window. That’s why your sidebar with width: 10% will span 10% of the entire browser window. All web developers intuitively know and use this fact.

What you may not know is how this works in theory. In theory, the width of the element is restricted by the width of the viewport. The element takes 100% of the width of that viewport.

The viewport, in turn, is exactly equal to the browser window: it’s been defined as such. The viewport is not an HTML construct, so you cannot influence it by CSS. It just has the width and height of the browser window — on desktop. On mobile it’s quite a bit more complicated.

Consequences

This state of affairs has some curious consequences. You can see one of them right here on this site. Scroll all the way up to the top, and zoom in two or three steps so that the content of this site spills out of the browser window.

Now scroll to the right, and you’ll see that the blue bar at the top of the site doesn’t line up properly any more.

image description

This behaviour is a consequence of how the viewport is defined. I gave the blue bar at the top a width: 100%. 100% of what? Of the element , which is as wide as the viewport, which is as wide as the browser window.

Point is: while this works fine at 100% zoom, now that we’ve zoomed in the viewport has become smaller than the total width of my site. In itself that doesn’t matter, the content now spills out of the element, but that element has overflow: visible, which means that the spilled-out content will be shown in any case.

But the blue bar doesn’t spill out. I gave it a width: 100%, after all, and the browsers obey by giving it the width of the viewport. They don’t care that that width is now too narrow.

image description

document width?

What I really need to know is how wide the total content of the page is, including the bits that “stick out.” As far as I know it’s not possible to find that value (well, unless you calculate the individual widths and margins of all elements on the page, but that’s error-prone, to put it mildly).

I am starting to believe that we need a JavaScript property pair that gives what I’ll call the “document width” (in CSS pixels, obviously).

image description

And if we’re really feeling funky, why not also expose this value to CSS? I’d love to be able to make the width: 100% of my blue bar dependent on the document width, and not the element ’s width. (This is bound to be tricky, though, and I wouldn’t be surprised if it’s impossible to implement.)

Browser vendors, what do you think?

Measuring the viewport

document. documentElement. clientWidth/Height

Meaning Viewport dimensions Measured in CSS pixels Browser errors None

You might want to know the dimensions of the viewport. They can be found in document.documentElement.clientWidth and -Height.

image description

If you know your DOM, you know that document.documentElement is in fact the element : the root element of any HTML document. However, the viewport is one level higher, so to speak; it’s the element that contains the element . That might matter if you give the element a width. (I don’t recommend that, by the way, but it’s possible.)

In that situation document.documentElement.clientWidth and -Height still gives the dimensions of the viewport, and not of the element . (This is a special rule that goes _only_ for this element _only_ for this property pair. In all other cases the actual width of the element is used.)

image description

So document.documentElement.clientWidth and -Height always gives the viewport dimensions, regardless of the dimensions of the element .

Two property pairs

But aren’t the dimensions of the viewport width also given by window.innerWidth/Height? Well, yes and no.

There’s a formal difference between the two property pairs: document.documentElement.clientWidth and -Height doesn’t include the scrollbar, while window.innerWidth/Height does. That’s mostly a nitpick, though.

The fact that we have two property pairs is a holdover from the Browser Wars. Back then Netscape only supported window.innerWidth/Height and IE only document.documentElement.clientWidth and -Height. Since then all other browsers started to support clientWidth/Height, but IE didn’t pick up window.innerWidth/Height.

Having two property pairs available is a minor nuisance on desktop — but it turns out to be a blessing on mobile, as we’ll see.

Measuring the element

document. documentElement. offsetWidth/Height

Meaning Dimensions of the element (and thus of the page). Measured in CSS pixels Browser errors IE measures the viewport, and not the element .

So clientWidth/Height gives the viewport dimensions in all cases. But where can we find the dimensions of the element itself? They’re stored in document.documentElement.offsetWidth and -Height.

image description

These properties truly give you access to the element as a block-level element; if you set a width, offsetWidth will reflect it.

image description

Event coordinates

pageX/Y, clientX/Y, screenX/Y

Meaning see main text Measured in see main text Browser errors IE doesn’t support pageX/Y. IE and Opera calculate screenX/Y in CSS pixels.

Then there are the event coordinates. When a mouse event occurs, no less than five property pairs are exposed to give you information about the exact place of the event. For our discussion three of them are important:

  1. pageX/Y gives the coordinates relative to the element in CSS pixels.
  2. clientX/Y gives the coordinates relative to the viewport in CSS pixels.
  3. screenX/Y gives the coordinates relative to the screen in device pixels.

image description

You’ll use pageX/Y 90% of the time; usually you want to know the event position relative to the document. The other 10% of the time you’ll use clientX/Y. You never ever need to know the event coordinates relative to the screen.

Media queries

Media queries

Meaning see main text Measured in see main text Browser errors IE doesn’t support them. For device-width/height Firefox uses the values screen.width/height would have if they are measured in CSS pixels. For width/height Safari and Chrome use the values documentElement .clientWidth/Height would have if they are measured in device pixels.

Finally, some words about media queries. The idea is very simple: you can define special CSS rules that are executed only if the width of the page is larger than, equal to, or smaller than a certain size. For instance:

div.sidebar {
    width: 300px;
}

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

}

Now the sidebar is 300px wide, except when the width is smaller than 400px, in which case the sidebar becomes 100px wide.

The question is of course: which width are we measuring here?

There are two relevant media queries: width/height and device-width/device-height.

  1. width/height uses the same values as documentElement .clientWidth/Height (the viewport, in other words). It works with CSS pixels.
  2. device-width/device-height uses the same values as screen.width/height (the screen, in other words). It works with device pixels.

image description

Which should you use? That’s a no-brainer: width, of course. Web developers are not interested in the device width; it’s the width of the browser window that counts.

So use width and forget device-width — on desktop. As we’ll see, the situation is much more messy on mobile.

Conclusion

That concludes our foray into the desktop browsers’ behaviour. The second part of this series ports these concepts to mobile and highlights some important differences with the desktop.

편집 게시물 신고 종료 삭제

질문 2013-08-27 17:19:22 +0900

director의 그라바타 이미지

수정 2013-08-28 00:18:33 +0900

0

A tale of two viewports — part one

viewport 와 window, screen 그리고 <html> 의 넓이 (width) 와 높이에 대해서 설명하려고 한다.

이 페이지는 데스크탑 브라우저에 관한 것이고, 다음 모바일 브라우저에 대해서 이야기 하는데에 도움이 될 것이다. 대부분의 웹 개발자는 설명하려는 개념들에 대해서 어느정도 이미 알고 있을지도 모른다. 모바일 기기에서도 같은 개념들이 적용되는데, 조금 더 복잡하다. 데스크탑에서 개념 정리를 하는 것이, 다음에 모바일에 대한 얘기를 진행할 때 도움이 될 것이다.

Concept: device pixels and CSS pixels

첫번째로 CSS pixel 과 device pixel 에 대해서 얘기하려고 한다.

Device pixel 은 우리가 이미 알고 있는 것이다. 우리가 사용하는 스크린의 width/height 로 표현되며, resolution 이라고도 부른다.

모니터가 1024px 일 때, html 요소에 width:128px 이라는 스타일을 준다고 해보자. 브라우저 화면을 최대로 키우면, 이 요소는 모니터에의 1/8 크기를 차지한다. (그렇지 않을 수도 있는 세부내용은 잠시 접어두자).

사용자가 화면을 확대/축소하면 (zoom), 이 계산이 달라지게 된다. 200% 로 확대하면, width:128px 인 요소는 1024px 모니터의 1/4 를 차지하게 된다.

대부분의 브라우저에서 zooming 은 pixel 을 "잡아 당긴" 듯이 구현된다. 즉 요소가 128px 사이즈에서 256px 로 변경되는 것이 아니라, 넓이가 128 CSS pixel 로 동일하게 가지고 있는데, device pixel 로는 256px 이 되게 된다.

200% 로 zoom 하면, 1 CSS px 길이가 2 device px 길이가 된다. (넓이는 4배가 된다.)

이미지를 보면 이해가 쉬울 것이다. 100% zoom 상태에서 4개의 pixel 은 다음처럼 보인다. CSS pixel 과 device pixel 이 일치하는 상태이다.

image description

zoom out 해보자. CSS pixel 이 작아진다. 하나의 device pixel 은 이제 여러개의 CSS pixel 에 해당하게 된다.

image description

zoom in 해보면 반대의 상황이 벌어진다. CSS pixel 이 커지고, 하나의 CSS pixel 이 여러개의 device pixel 에 해당하게 된다.

image description

요점은, CSS pixel 만 신경쓰면 된다는 것이다. 여러분의 style sheet 은 CSS pixel 에만 영향을 받는다.

Device pixel 은 웹 개발자에게는 별로 의미가 없다. 사용자에게는 다르다: 사용자는 페이지를 zoom in 하거나 out 해서 페이지를 쉽게 볼 수 있게 조절할 수 있다. 브라우저가 CSS layout (역주: 여러분의 페이지) 가 확대하던지 축소하던지 알아서 할 것이기 때문에, 웹 개발자는 zoom 에 대해 별로 신경 쓸 일이 없다.

100% zoom

zoom 이 100% 인 예제 그림을 보여주었는데, 좀더 명확히 100% zoom 이 무엇을 의미하는지 정의해보자:

zoom level 100% 는 1 CSS pixel 과 1 device pixel 의 크기가 동일한 상태이다.

100% zoom 의 개념은 다음 내용들을 설명할 때 필요하다. 하지만 개발할 때는 크게 신경쓰지 않아도 되는 개념이다. 보통 100% zoom 상태로 사이트를 테스트 할테지만, 유저가 zoom 기능을 사용하더라도 사이트가 같은 비율 (넓이, 높이) 로 확대/축소 되기 때문이다.

Screen size

좀 더 실용성 있는 길이들에 대해서 살펴보자. screen.widthscreen.height 부터 살펴보자. 이 값들은 유저의 스크린의 넓이와 높이이다. 이 길이는 device pixel 단위로 재고, 변하지 않는다. 이 값들은 모니터의 성질이지, 브라우저의 성질이 아니다.

image description

근데 이 정보를 어디다 사용하나?

사용할 곳이 없다. 사용자 모니터의 크기는 중요하지 않다 - 통계를 내는 목적으로 사용할 것이 아니라면 말이다.

Window size

모니터 크기에는 관심이 없지만, 브라우저 창의 내부 크기를 알고 싶어할 것이다. css 에서 정확히 이 크기만큼 사용할 수가 있다. 이 크기를 window.innerWidthwindow.innerHeight 로 얻어올 수 있다.

image description

브라우저 창의 내부 크기는 CSS pixel 단위로 측정된다. 브라우저 창에 얼마만큼의 layout 을 집어넣을 수 있는지 알아야 할 때가 있다. 그리고 사용자가 zoom in 하면, 집어넣을 수 있는 양은 줄어든다. 즉 zoom in 시 브라우저 창의 크기 (역주: CSS pixel 로 재었을 때, zoom in 시 CSS pixel 이 커지기 때문에), 는 줄어들다. 즉 window.innerWidth 와 innerHeight 이 줄어들게 된다.

(Opera 는 예외이다. zoom in 시 window.innerWidth/Height 이 줄어들지 않는다: 오페라에서는 device pixel 을 이용하기 때문이다. 나중에 보겠지만, 데스크탑에서 귀찮은 정도이지만, 모바일에서는 치명적이다.)

image description

이 width 와 height 는 scrollbar 를 포함하는 것을 눈여겨 보라. 이 scrollbar 가 내부 윈도우의 영역으로 인식된다. (역사적인 이유가 있다.)

Scrolling offset

window.pageXOffsetwindow.pageYOffset 은 문서가 얼마나 scroll 되었는지를 보여준다.

image description

이 길이들은 CSS pixel 단위이다. zoom 상태가 어떠한지에 상관없이, 문서가 얼마나 스크롤 됐는지 알고 싶을 때, 이 값을 사용한다.

유저가 스크롤한 상태에서 zoom in 을 하면 window.pageX/YOffset 은 변할 것이다. 하지만 브라우저는, 사용자가 zoom 을 하더라도 화면 상단에 같은 요소를 보여주려고 노력을 한다. 완벽히 동작하지는 않지만, window.pageX/YOffset 이 많이 변하지도 않는다: 스크롤된 CSS pixel 길이는 (대략) 비슷하게 유지된다.

image description

Concept: the viewport

JavaScript 성질들을 살펴보기 전에, 또 하나의 컨셉을 살펴보려한다: viewport 가 그것이다.

viewport 의 기능은 <html> 요소를 제어하는 것이다.

무슨 뜻인가, 예제를 들어 설명하려고 한다. 반응형 layout 이 있고, sidebar 의 길이를 width: 10% 라고 주었다고 해보자. 브라우저 크기를 변경할 때, sidebar 의 크기도 따라서 변한다. 그런데 내부적으로 어떻게 동작하는 것일까?

sidebar 는 부모 넓이의 10% 넓이를 가지게 된다. sidebar 의 부모가 <body> 라고 해보자. (그리고 body 에 width 를 주지 않았다). <body> 의 width 는 몇이 되는가?

일반적으로, 모든 block-level 요소들은 부모 넓이의 100% 넓이를 갖게 된다. (예외도 있지만, 여기선 무시하자). 그래서 <body> 는 부모 인 <html> 의 넓이를 갖게 된다.

그럼 html 의 넓이는 얼마인가? 브라우저 창 크기와 동일할 것이다. 그래서 width: 10% 인 sidebar 는 전체 브라우저 창의 10% 넓이를 차지하게 된다. 모든 웹 개발자들은 직관적으로 이 개념을 이용하고 사용한다.

하지만 이론적으로 (역주: 브라우저 창크기가 어떻게 정의되는지) 어떻게 동작하는지 잘 모를 수도 있다. <html> 요소는 viewport 의 넓이에 의해 제한을 받는다. <html> 은 viewport 넓이의 100% 를 사용한다.

viewport 는 browser 의 창과 동일하다: 그렇게 정의되어 있다. viewport 는 HTML 요소가 아니다. CSS 로 변경할 수도 없다. 단지 browser 창의 넓이와 높이를 가진다. 적어도 데스크탑에서는 말이다, 모바일에서는 좀 더 복잡해진다.

Consequences

viewport 와 html 의 넓이를 위처럼 정의하였기 때문에 생기는 현상을 살펴 볼 것이다. 이 페이지의 최상단으로 스크롤하여, zoom in 해보면, 컨텐츠가 브라우저 창 밖으로 삐져 나오는 것을 볼 수 있다.

zoom in 한 뒤, 오른쪽으로 스크롤 해 보면, 사이트의 위 파란 bar 부분이 이상한 것을 볼 수 있다.

image description

이것은 viewport 의 성질 때문에 그렇다. 상단의 파란 bar 에 width: 100% 스타일을 주었다. 무엇의 100% ? <html> 의 100% 를 주었다. 그리고 <html> 은 viewport 와 같은 넓이를 가지고 있고, viewport 는 브라우저 창과 같은 넓이를 가지고 있다.

요점은: 100% zoom 에서는 아무 문제가 없다. 그런데 zoom in 을 하게 되면, viewport 는 사이트의 넓이보다 작아진다. (역주: 어떤 이미지를 왼쪽에서 800px 떨어진 곳에 놓았을 때, zoom in 하여 viewport 가 700 이 되면, bar 는 700px 인데, 이미지는 800px 인 곳에 놓이게 되어 삐져나온다) 페이지 내용들이 <html> 을 넘치고, <html>overflow: visible 속성을 가지고 있으면, 넘쳐 나온 컨텐츠들이 보여지게 된다.

파란 bar 가 삐져 나오진 않는다. width: 100% 를 주었기 때문에, browser 는 viewport 의 넓이만큼을 bar 에 할당하게 된다. browser 는 이제 그 길이가 너무 작다는 것은 신경쓰지 않는다.

image description

document width?

내가 알고 싶은 것은 페이지의 내용의 실제 사이즈가 어떻게 되는가 이다. 저렇게 "삐져나오는 것들" 을 포함해서 말이다. 내가 알기론 이 값을 얻을 수 있는 방법은 없다. (모든 요소들의 마진과 width 를 더하는 방법이 있지만, 에러 없이 값을 얻긴 쉽지 않을 것이다)

"document width" 라고 부를 수 있는, 이 페이지의 실제 크기를 나타낼 수 있는 JavaScript 속성이 있으면 어떨까 싶다. (물론 CSS pixel 단위여야 할 것이다.)

image description

CSS 에서도 이 값을 사용할 수 있다면, 파란색 bar 의 width: 100%<html> 의 넓이가 아닌 실제 페이지의 넓이를 사용하도록 할 수 있을 것이다. (아마도 구현하기는 쉽지 않을 것이다.)

브라우저 만드는 분들 어떻게 생각하는가?

Measuring the viewport

viewport 의 크기를 알고 싶을 때가 있을 것이다. document.documentElement.clientWidthclientHeight 로 얻을 수 있다.

image description

DOM 에 대해 알고 있다면, document.documentElement 이 사실은 <html> 요소라는 것을 알고 있을 것이다: HTML 문서의 최상단 요소 말이다. 하지만, viewport 는 하나 더 위에 존재하는 것이라 보면 된다. viewport 는 <html> 요소를 포함하는 요소이다. <html>width 를 줄 경우가 생기면, 이 둘의 차이를 명확히 보게 될 것이다. (물론 <html>width 를 주는 것을 권하지는 않는다. 단지 가능하다는 것일 뿐)

이 경우에, document.documentElement.clientWidth 는 여전히 viewport 의 크기를 준다, <html> 의 크기를 주는 것이 아니다. (이것은 매우 특별한 경우로, 다른 모든 경우에 있어서는 width 란 어떤 실존하는 요소의 실제 width 이다)

image description

즉, document.documentElement.clientWidth<html> 의 크기와 상관 없이 항상 viewport 의 넓이를 준다.

Two property pairs

그런데 window.innerWidth/Height 와 viewport 의 크기와는 어떻게 다른 것인가?

document.documentElement.clientWidth 는 스크롤 바 영역을 포함하지 않고 window.innerWidth/Height 은 스크롤을 포함한다.

비슷한 속성이 두개 존재하는 이유는 과거의 브라우저 전쟁 때문이다. Netscape 는 window.innerWidth/Height 만을 지원했고, IE 는 document.documentElement.clientWidth 만을 지원했다. 다른 브라우저들이 clientWidth/Height 를 채용했으나 IE 는 innerWidth/Height 를 채용하지 않았다.

이 두가지 속성을 가지고 있는 것은 데스크탑 환경에서는, 약간 귀찮은 일이다 -하지만 곧 살펴보겠지만, 모바일에서는 행운이다.

Measuring the element

clientWidth/Height 는 항상 viewport 의 크기를 준다. 그런데 <html> 요소의 크기는 어떻게 찾는가? document.documentElement.offsetWidth 로 얻을 수 있다.

image description

이 속성으로 <html> 을 block-level 요소처럼 다룰 수 있다; width 를 설정하면 offsetWidth 도 변경된다.

image description

Event coordinates

그리고 event 좌표 개념이 있다. mouse 이벤트가 발생할 때, 5개 이상의 속성 pair 들이, 이벤트가 어디서 발생했는지 알려준다. 우리가 살펴볼 것은 다음 세가지이다:

  1. pageX/Y<html> 기준으로 CSS pixel 단위 좌표값을 준다.
  2. clientX/Y 는 viewport 기준으로 CSS pixel 단위 좌표값을 준다.
  3. screenX/Y 는 screen 기준으로 device pixel 단위 좌표값을 준다.

image description

pageX/Y 를 90% 이상 사용할 것이다; 대부분의 경우에, 이벤트 위치가, 문서상에서 어디 위치하는지 알아야 된다. 나머지 10% 경우엔, clientX/Y 를 사용할 것이다. 스크린 기준으로 어디에서 이벤트가 발생했는지 알아야 할 일은 별로 없다.

Media queries

age is larger than, equal to, or smaller than a certain size. For instance:

마지막으로, media query 에 대한 얘기를 해보자. 개념은 매우 간단하다: page 의 사이즈에 따라 적용할 CSS 법칙들을 정의하는 것이다:

div.sidebar {
    width: 300px;
}

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

}

sidebar 는 300px 이다. 그런데 width 가 400px 보다 작아지면 sidebar 는 100px 이 된다.

문제는, 어떤 width 를 재는가 이다.

media query 에서는 width/heightdevice-width/device-height 두가지를 사용한다.

  1. width/heightdocumentElement .clientWidth/Height 와 같은 값을 사용한다. (viewport 의 크기이다) 그리고 CSS pixel 단위이다.
  2. device-width/device-heightscreen.width/height (즉 screen 크기) 와 같은 값을 사용한다. device pixel 단위이다.

image description

어떤것을 이용해야 할까? 쉽다: width 이다. 웹 개발자는 device width 에는 신경쓰지 않는다. browser 창의 크기가 중요하다.

width 를 사용하고 device-width 는 잊어라 - 데스크탑에선 말이다. 곧 보게 되겠지만 모바일에선 훨씬 복잡하다.

Conclusion

데스크탑 브라우저의 여러가지 크기에 대해서 알아보았다. 다음번에는 이 개념들이 모바일에서 어떻게 적용되는지 차이점은 무엇인지 살펴볼 것이다.

편집 게시물 신고 삭제 publish 링크

게시 2013-08-27 18:57:56 +0900

director의 그라바타 이미지

통계

질문: 2013-08-27 17:19:22 +0900

읽음: 1,482 시간

마지막 업데이트: Aug 27 '13