The position of a document element is measured in CSS pixels, with the x coordinate
increasing to the right and the y coordinate increasing as we go down. There are two
different points we can use as the coordinate system origin, however: the x and y
coordinates of an element can be relative to the top-left corner of the document or
relative to the top-left corner of the viewport in which the document is displayed. In
top-level windows and tabs, the "viewport" is the portion of the browser that actually
displays document content: it excludes browser "chrome" such as menus, toolbars, and
tabs. For documents displayed in <iframe> tags, it is the iframe element in the DOM that
defines the viewport for the nested document. In either case, when we talk about the
position of an element, we must be clear whether we are using document coordinates or
viewport coordinates. (Note that viewport coordinates are sometimes called "window
coordinates.")
If the document is smaller than the viewport, or if it has not been scrolled, the
upper-left corner of the document is in the upper-left corner of the viewport and the
document and viewport coordinate systems are the same. In general, however, to convert
between the two coordinate systems, we must add or subtract the scroll offsets. If an
element has a y coordinate of 200 pixels in document coordinates, for example, and if the
user has scrolled down by 75 pixels, then that element has a y coordinate of 125 pixels
in viewport coordinates. Similarly, if an element has an x coordinate of 400 in viewport
coordinates after the user has scrolled the viewport 200 pixels horizontally, then the
element's x coordinate in document coordinates is 600.
If we use the mental model of printed paper documents, it is logical to assume that every
element in a document must have a unique position in document coordinates, regardless of
how much the user has scrolled the document. That is an appealing property of paper
documents, and it applies for simple web documents, but in general, document coordinates
don't really work on the web. The problem is that the CSS overflow property allows
elements within a document to contain more content than it can display. Elements can have
their own scrollbars and serve as viewports for the content they contain. The fact that
the web allows scrolling elements within a scrolling document means that it is simply not
possible to describe the position of an element within the document using a single (x,y)
point.
Because document coordinates don't really work, client-side JavaScript tends to use
viewport coordinates. The getBoundingClientRect() and elementFromPoint() methods
described next use viewport coordinates, for example, and the clientX and clientY
properties of mouse and pointer event objects also use this coordinate
system.
When you explicitly position an element using CSS position:fixed, the top and left
properties are interpreted in viewport coordinates. If you use position:relative, the
element is positioned relative to where it would have been if it didn't have the position
property set. If you use position:absolute, then top and left are relative to the
document or to the nearest containing positioned element. This means, for example, that
an absolutely positioned element inside a relatively positioned element is positioned
relative to the container element, not relative to the overall document. It is sometimes
very useful to create a relatively positioned container with top and left set to 0 (so
the container is laid out normally) in order to establish a new coordinate system origin
for the absolutely positioned elements it contains. We might refer to this new coordinate
system as "container coordinates" to distinguish it from document coordinates and
viewport coordinates.