关于DOM中元素位置、大小的API

综述

DOM 的 API 繁多复杂，拿一个节点来说

1. 首先你要根据选择器或节点的特征获取到这个元素或者干脆创建一个节点
2. 然后你要使用具体的 API 来了解这个元素，如获取元素的style对象、位置、大小、属性、事件等
3. 最后你要使用强力的 API 对节点进行操作，如改变前面了解到的信息甚至对节点整体进行操作

不论你使用什么框架，界面展示的最终环节基本就靠上面提到的 DOM API 进行，而框架的作用只是替你做了这些比较繁琐、底层的东西，所以我们了解 DOM 的 API 还是十分重要的。

最近布局中遇到使用到一些 API ，顺手总结一下。

布局中常会用到获取元素大小的API，我们比较常用的应该有如下几个

1. 偏移量 offset
2. 客户区大小 client
3. 滚动大小 scroll
4. 综合函数 getBoundingClientRect()
5. 可视区域大小 inner

偏移量

偏移量（offset dimension）是依据元素在屏幕上占用的所有可见的空间进行计算的，显然传统意义上的可见区域要包括元素自身内容、内边距、滚动条、边框。其有四个属性

1. offsetHeight，垂直方向占用空间，包括border，单位为px
2. offsetWidth，水平方向占用空间，其他同上
3. offsetLeft，元素外边框到其包含元素的内边框的距离
4. offsetTop，同上

偏移量个人用的比较多的还是求大小的时候，因为求位置必须求出每一个元素的偏移量，向上叠加到根元素，同时需要另外一个跟大小无关的属性offsetParent，此属性指向包含元素，包含元素不一定是parentNode，因为此包含元素必须有大小。

下面是简单的递归求top距离代码

function getOffsetTop(elem, num){    num += elem.offsetTop    let parent = elem.offsetParent    if(parent !== null){        return getOffsetTop(parent, num)    }    return num}

后面会说到，求总体偏移量其实用函数 getBoundingClientRect 比较方便

客户区大小

客户区大小（client dimension）是元素内容以及其内边距所占据空间大小，其只有两个属性

1. clientWidth，同上
2. clientHeight，同上

因为除非我们在将其当做一个容器看待时，大多数情况下我们都会关注整个元素的layout大小，而不会在意元素内容区有多大，所以这个属性其实用到的不多，更多的是作为一种求视口大小的方案，比如

document.documentElement.clientWidthdocument.body.clientHeight

当然这个要求 HTML 和 body 元素占据全部视口空间，即我们常用的

html, body{    width: 100%;    height: 100%;}

滚动大小

滚动大小（scroll dimension）是包含滚动内容的元素大小，其有四个属性

1. scrollHeight，没有滚动条的情况下，元素内容的总高度。
2. scrollWidth，同上
3. scrollLeft，被隐藏自内容区域左侧的像素数。
4. scrollTop，同上

scroll常被用在控制滚动条上，比如最常用的返回顶部

window.addeventListener("scroll", () => {    // 判断是否到达一定距离，一般是一个首屏的距离  elem为带滚动条的元素    if(elem.scrollTop < window.innerHeight){        elem.scrollTop = 0    }})

另外就是衡量比较长的内容总体有多长，使用scrollHeight

getBoundingClientRect

每个元素都有一个getBoundingClientRect方法，其返回值为一个矩形对象的详情，包含8个属性（chrome60+实测），这里我们主要讲6个属性（除了x，y）

1. left，相对于视口的位置，跟offsetLeft类似
2. right，同上
3. top，同上
4. bottom，同上
5. width，类似offsetWidth，等于left-right
6. height，同上

浏览器会支持度比较好，都是比较使用的属性方便起见个人用的比较多。

浏览器可视区域大小

方法比较多，我一般会用比较直接的innnerWidth，具体方案可以看这篇文章

最后上一个很老的总图

随着标准的统一、规范化和浏览器各种支持度比较好，很多以前的ployfill方案都离我们远去了，但比较有用的 API 最好还是熟悉，也希望标准越来越友好，前端越来越规范。