jeena/en.javascript.info
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

minor

Browse source
This commit is contained in:
Ilya Kantor 2019-08-05 17:37:44 +03:00
parent 07975a7b38
commit 2ffe7c4635
2 changed files with 17 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

2
2-ui/1-document/09-size-and-scroll/1-get-scroll-height-bottom/task.md
View file

@ -4,7 +4,7 @@ importance: 5
# What's the scroll from the bottom? # What's the scroll from the bottom?
The `elem.scrollTop` property is the size of the scrolled out part from the top. How to get "`scrollBottom`" -- the size from the bottom? The `elem.scrollTop` property is the size of the scrolled out part from the top. How to get the size from the bottom scroll (let's call it `scrollBottom`)?
Write the code that works for an arbitrary `elem`. Write the code that works for an arbitrary `elem`.

34
2-ui/1-document/09-size-and-scroll/article.md
View file

@ -32,28 +32,24 @@ The element looks like this:
You can [open the document in the sandbox](sandbox:metric). You can [open the document in the sandbox](sandbox:metric).
```smart header="Mind the scrollbar" ```smart header="Mind the scrollbar"
The picture above demonstrates the most complex case when the element has a scrollbar. Some browsers (not all) reserve the space for it by taking it from the content. The picture above demonstrates the most complex case when the element has a scrollbar. Some browsers (not all) reserve the space for it by taking it from the content (labeled as "content width" above).
So, without scrollbar the content width would be `300px`, but if the scrollbar is `16px` wide (the width may vary between devices and browsers) then only `300 - 16 = 284px` remains, and we should take it into account. That's why examples from this chapter assume that there's a scrollbar. If there's no scrollbar, then things are just a bit simpler. So, without scrollbar the content width would be `300px`, but if the scrollbar is `16px` wide (the width may vary between devices and browsers) then only `300 - 16 = 284px` remains, and we should take it into account. That's why examples from this chapter assume that there's a scrollbar. Without it, some calculations are simpler.
``` ```
```smart header="The `padding-bottom` area may be filled with text" ```smart header="The `padding-bottom` area may be filled with text"
Usually paddings are shown empty on illustrations, but if there's a lot of text in the element and it overflows, then browsers show the "overflowing" text at `padding-bottom`. Usually paddings are shown empty on our illustrations, but if there's a lot of text in the element and it overflows, then browsers show the "overflowing" text at `padding-bottom`, that's normal.
That's a note to avoid confusion, as `padding-bottom` is set in further examples, unless explicitly specified otherwise.
``` ```
## Geometry ## Geometry
Here's the overall picture: Here's the overall picture with geometry properties:
![](metric-all.svg) ![](metric-all.svg)
Values of these properties are technically numbers, but these numbers are "of pixels", so these are pixel measurements. Values of these properties are technically numbers, but these numbers are "of pixels", so these are pixel measurements.
They are many properties, it's difficult to fit them all in the single picture, but their values are simple and easy to understand. Let's start exploring the properties starting from the outside of the element.
Let's start exploring them from the outside of the element.
## offsetParent, offsetLeft/Top ## offsetParent, offsetLeft/Top
@ -67,7 +63,7 @@ That's the nearest ancestor, that satisfies following conditions:
2. or `<td>`, `<th>`, `<table>`, 2. or `<td>`, `<th>`, `<table>`,
2. or `<body>`. 2. or `<body>`.
Properties `offsetLeft/offsetTop` provide x/y coordinates relative to its upper-left corner. Properties `offsetLeft/offsetTop` provide x/y coordinates relative to `offsetParent` upper-left corner.
In the example below the inner `<div>` has `<main>` as `offsetParent` and `offsetLeft/offsetTop` shifts from its upper-left corner (`180`): In the example below the inner `<div>` has `<main>` as `offsetParent` and `offsetLeft/offsetTop` shifts from its upper-left corner (`180`):
@ -86,7 +82,6 @@ In the example below the inner `<div>` has `<main>` as `offsetParent` and `offse
![](metric-offset-parent.svg) ![](metric-offset-parent.svg)
There are several occasions when `offsetParent` is `null`: There are several occasions when `offsetParent` is `null`:
1. For not shown elements (`display:none` or not in the document). 1. For not shown elements (`display:none` or not in the document).
@ -143,7 +138,9 @@ What's the difference?
It becomes visible when the document is right-to-left (the operating system is in Arabic or Hebrew languages). The scrollbar is then not on the right, but on the left, and then `clientLeft` also includes the scrollbar width. It becomes visible when the document is right-to-left (the operating system is in Arabic or Hebrew languages). The scrollbar is then not on the right, but on the left, and then `clientLeft` also includes the scrollbar width.
In that case, `clientLeft` would be not `25`, but with the scrollbar width `25 + 16 = 41`: In that case, `clientLeft` would be not `25`, but with the scrollbar width `25 + 16 = 41`.
Here's the example in hebrew:
![](metric-client-left-top-rtl.svg) ![](metric-client-left-top-rtl.svg)
@ -155,7 +152,9 @@ They include the content width together with paddings, but without the scrollbar
![](metric-client-width-height.svg) ![](metric-client-width-height.svg)
On the picture above let's first consider `clientHeight`: it's easier to evaluate. There's no horizontal scrollbar, so it's exactly the sum of what's inside the borders: CSS-height `200px` plus top and bottom paddings (`2 * 20px`) total `240px`. On the picture above let's first consider `clientHeight`.
There's no horizontal scrollbar, so it's exactly the sum of what's inside the borders: CSS-height `200px` plus top and bottom paddings (`2 * 20px`) total `240px`.
Now `clientWidth` -- here the content width is not `300px`, but `284px`, because `16px` are occupied by the scrollbar. So the sum is `284px` plus left and right paddings, total `324px`. Now `clientWidth` -- here the content width is not `300px`, but `284px`, because `16px` are occupied by the scrollbar. So the sum is `284px` plus left and right paddings, total `324px`.
@ -167,8 +166,7 @@ So when there's no padding we can use `clientWidth/clientHeight` to get the cont
## scrollWidth/Height ## scrollWidth/Height
- Properties `clientWidth/clientHeight` only account for the visible part of the element. These properties are like `clientWidth/clientHeight`, but they also include the scrolled out (hidden) parts:
- Properties `scrollWidth/scrollHeight` also include the scrolled out (hidden) parts:
![](metric-scroll-width-height.svg) ![](metric-scroll-width-height.svg)
@ -232,7 +230,7 @@ alert( getComputedStyle(elem).width ); // show CSS width for elem
Why should we use geometry properties instead? There are two reasons: Why should we use geometry properties instead? There are two reasons:
1. First, CSS width/height depend on another property: `box-sizing` that defines "what is" CSS width and height. A change in `box-sizing` for CSS purposes may break such JavaScript. 1. First, CSS `width/height` depend on another property: `box-sizing` that defines "what is" CSS width and height. A change in `box-sizing` for CSS purposes may break such JavaScript.
2. Second, CSS `width/height` may be `auto`, for instance for an inline element: 2. Second, CSS `width/height` may be `auto`, for instance for an inline element:
```html run ```html run
@ -270,9 +268,9 @@ Elements have the following geometry properties:
- `offsetParent` -- is the nearest positioned ancestor or `td`, `th`, `table`, `body`. - `offsetParent` -- is the nearest positioned ancestor or `td`, `th`, `table`, `body`.
- `offsetLeft/offsetTop` -- coordinates relative to the upper-left edge of `offsetParent`. - `offsetLeft/offsetTop` -- coordinates relative to the upper-left edge of `offsetParent`.
- `offsetWidth/offsetHeight` -- "outer" width/height of an element including borders. - `offsetWidth/offsetHeight` -- "outer" width/height of an element including borders.
- `clientLeft/clientTop` -- the distance from the upper-left outer corner to its upper-left inner corner. For left-to-right OS they are always the widths of left/top borders. For right-to-left OS the vertical scrollbar is on the left so `clientLeft` includes its width too. - `clientLeft/clientTop` -- the distance from the upper-left outer corner the inner corner. For left-to-right OS they are always the widths of left/top borders. For right-to-left OS the vertical scrollbar is on the left so `clientLeft` includes its width too.
- `clientWidth/clientHeight` -- the width/height of the content including paddings, but without the scrollbar. - `clientWidth/clientHeight` -- the width/height of the content including paddings, but without the scrollbar.
- `scrollWidth/scrollHeight` -- the width/height of the content, just like `clientWidth/clientHeight`, but also include scrolled-out, invisible part of the element. - `scrollWidth/scrollHeight` -- the width/height of the content, just like `clientWidth/clientHeight`, but also include scrolled-out, invisible part of the element.
- `scrollLeft/scrollTop` -- width/height of the scrolled out upper part of the element, starting from its upper-left corner. - `scrollLeft/scrollTop` -- width/height of the scrolled out upper part of the element, starting from its upper-left corner.
All properties are read-only except `scrollLeft/scrollTop`. They make the browser scroll the element if changed. All properties are read-only except `scrollLeft/scrollTop` that make the browser scroll the element if changed.