龙喵专栏 /前端 /内容

彻底解决滚动穿透方案

版权声明:龙喵网!!!网站网址:http://ailongmiao.com

什么是滚动穿透

滚动穿透

如图所示,有一层遮罩蒙层覆盖在body上时,当我们滚动遮罩层,它下面的内容也会跟着一起滚动,看起来好像是上面的滚动事件穿透到下面的DOM元素上一样,我们称之为滚动穿透。

阻止冒泡?

刚开始遇到这个问题的同学可能会联想到是不是由于事件冒泡到body上引起的,于是监听 scroll/touchmove事件,阻止事件冒泡。

事实上,这并没有什么卵用。

首先,一般而言滚动不是我们自己监听事件去改变元素的位置而实现的,当我们设置 overflow:scroll/auto时,实际上是浏览器原生实现的滚动效果。

其次, scroll事件对于普通Element元素是不冒泡的,可参见MDN:

Bubbles
Not on elements, but bubbles to the default view when fired on the document

所有的滚动都是在 Document上形成了一个 pending队列,然后按照一定的规则触发,详见W3C规范:

When asked to run the scroll steps for a Document doc, run these steps:
For each item target in doc’s pending scroll event targets, in the order they were added to the list, run these substeps:
If target is a Document, fire an event named scroll that bubbles at target.
Otherwise, fire an event named scroll at target.
Empty doc’s pending scroll event targets.

当我们滚动鼠标滚轮,或者滑动手机屏幕时,触发对象可分为两种类型(详见W3C规范):

  1. viewport被触发滚动, eventtarget为关联的 Document
  2. element元素被触发滚动,通常也就是我们添加 overflow滚动属性的element元素, eventtarget为相应的 node element

注意到这里,只有两种类型,当我们触发滚轮或滑动时,如果当前元素没有设置 overflow这样的属性,同时也没有 preventDefault掉原生的滚动/滑动事件,那么此时触发的是 viewport的滚动, position:fixed的元素并没有什么例外。

由此可见,滚动穿透问题其实并不是一个浏览器的bug(虽然在ios下fixed定位确实会导致很多bug),它是完全符合规范的,滚动的原则应该是 scrollforwhat can scroll,不应该因为某个元素的 CSS定位导致滚轮失效或者滑动失效。

然而对于我们的业务而言, ModalLayer元素触发整个 viewport滚动往往是一个bug,它会给用户带来非常不好的体验,因此我们需要去解决它。

加overflow:hidden?

既然它触发了整个 viewport的滚动,那么我们给 body上加个 overflow:hidden,让整个body变成不可滚动的元素:

html, body {
   overflow: hidden;
}

这个想法很美好,在不侵入JS的情况下禁止滚动,然而:

只加 overflow:hidden对移动端是无效的!

当body的高度被内容撑开而滚动时,如果不对body的高度加以限制,只加入 overflow:hidden,此时在移动端依然可以滚动。

我们可以在加入 overflow:hidden的同时选择性做:

  1. 将 html,body的高度设置为 100%

  2. 将 html,body设置为绝对定位

这两个操作都可以完美地禁止整个body的滚动,但带来的最大问题是:

该方案会让浏览器的滚动条默认重置于初始位置

要解决这个问题,首先想到的方案是在添加 overflow之前,先记录当前浏览器的 scrollTop值,然后在添加之后重置 scrollTop,效果如下:

滚动穿透(请注意蒙层出现时,底部列表发生的变化)

在这个交互过程中,浮层弹出时,底部列表首先滚动条被置为初始态,关闭浮层后重置为之前的记录位置。实际上浮层的弹出背景是有一次跳变。

这种方案实现简单,若认为重置滚动条的跳变无伤大雅的情况下可以优先采用此方案。

阻止body的默认滚动?

直接阻止 documenttouchmove事件:

document.ontouchmove = e => {
	e.preventDefault();
};

看起来好像非常严格,将整个页面的滚动全部禁止,但实践后发现:

该方案好像在Android中不生效?

这似乎颠覆了我们平时的认知,连 document的touchmove都禁不掉默认滚动?

在仔细进一步的定位下,最终确定罪魁祸首原来是:passive event

我们知道,chrome 51引入了 passiveeventlisteners以提高滚动性能,同时它也合入了标准,具体可查看chrome passive-event-listeners

简单介绍一下原理,就是我们监听 touchmove事件时,在之前是有一个小延迟触发的,因为浏览器不知道我们是否要 preventDefault,所以等到大概200ms左右才能真正收到监听回调。

chrome在56版本将 addEventListner默认的 passive置为true,具体请参见这里,这样浏览器就能知道这个 addEventListner是不用 preventDefault的,立即可触发滚动事件。

在Android的手q和微信中使用的是X5内核,它是基于blink内核的,因此同样有关于 passiveevent的优化。所以我们需要加入 addEventListner的第三个参数:

document.addEventListener(
	'touchmove',
	e => {
		e.preventDefault();
	},
	{ passive: false },
);

现在Android的手机也可以禁止掉浏览器的滚动了。当然 addEventListner的第三个参数是最新标准才更改为对象的,因此存在一些兼容性问题,我们需要做一个检测:

var supportsPassive = false;
try {
  var opts = Object.defineProperty({}, 'passive', {
	get: function() {
	  supportsPassive = true;
	}
  });
  window.addEventListener("test", null, opts);
} catch (e) {}

采用这种方案带来的最大的问题是:

所有的滚动事件全部被禁止了!

假如我们的浮层上真的需要滚动事件,就不能阻止这些元素的默认行为。

浮层上面的滚动元素?

既然浮层上面有需要滚动的元素,最简单的方案就是有选择性地阻止默认事件:

document.addEventListener(
  'touchmove',
  e => {
	const excludeEl = document.querySelectorAll('.can-scroll');
	const isExclude = [].some.call(excludeEl, (el: HTMLElement) =>
	  el.contains(e.target),
	);
	if (isExclude) {
	  return true;
	}
	e.preventDefault();
},
{ passive: false },

我们简单地规定带有 can-scroll类名的元素是可滚动的,这些元素以及他们的子元素全部采用不阻止默认事件策略。

这样一来只需要在可滚动的容器上加入 can-scroll类名即可滚动,但是这种滚动又随之带来一个问题:

当滚动到元素顶部和底部再继续滚动时,又会触发滚动穿透!

正如一开始介绍穿透问题那样,当滑动超出边界时,一样会触发默认的滚动穿透。对此,我们必须要在边界条件时阻止滚动:

// 监听所有可滚动元素的滚动事件
[].forEach.call(scrollEl, (el: HTMLElement) => {
  let initialY = 0;
  el.addEventListener('touchstart', e => {
	if (e.targetTouches.length === 1) {
	  // 单点滑动
	  initialY = e.targetTouches[0].clientY;
	}
  });
  el.addEventListener('touchmove', e => {
	if (e.targetTouches.length === 1) {
	  // 单点滑动
	  const clientY = e.targetTouches[0].clientY - initialY;
	  if (
		el.scrollTop + el.clientHeight >= el.scrollHeight &&
		clientY < 0
	  ) {
		// 向下滑至底部
		return e.preventDefault();
	  }
	  if (el.scrollTop <= 0 && clientY > 0) {
		// 向上滑至顶部
		return e.preventDefault();
	  }
	}
  });
});

经过这样的调整之后,看起来滚动穿透问题得到了完美的解决,但是:

当多个浮层同时存在时,滚动穿透将再次触发

支持多浮层

多浮层穿透

之所以会出现多浮层问题,是因为我们往 document上绑事件只绑一次,这个是对的,但是每个浮层关闭的时候都会触发 unbind,就会导致绑定的事件直接解绑,但其实这时还有其他浮层需要阻止滚动穿透。

解决办法也很简单,每一个浮层作为一个实例,我们定义一个Set来存储当前锁定的浮层:

const lockedList = new Set();
lock() {
  lockedList.add(this);
  // 省略其他逻辑
}
unlock() {
  lockedList.delete(this);
  if (lockedList.size <= 0) {
	this.destroy();
  }
}

只有当这个set没有值的时候,也就是所有的弹框均调用 unlock之后,再去解绑事件。

这样,整个方案就比较完美了:

更好的组件调用

经过一系列折腾,我们终于解决了问题,也给出了一个相对较为完美的解决方案。可是从使用性质来考虑,还不是很便捷,尤其是现在如 ReactVue这类框架中,还需要考虑浮层什么时候实例化,什么时候应当调用 lockunlock显得有些麻烦,因此编写了一个React版本的组件:

componentDidMount() {
	const opts = this.props.selector
	  ? { selector: this.props.selector }
	  : undefined;
	this.lockScroll = new LockScroll(opts);
	this.updateScrollFix();
}
updateScrollFix() {
	const { lock } = this.props;
	if (lock) {
	  this.lockScroll.lock();
	} else {
	  this.lockScroll.unlock();
	}
}
componentDidUpdate(prevProps: ScrollFixProps) {
	if (prevProps.lock !== this.props.lock) {
	  this.updateScrollFix();
	}
}
componentWillUnmount() {
	console.log('scrollfix component will unmount!');
	this.lockScroll.unlock();
}

思路也非常简单,组件传入一个 lock参数,当组件挂载时创建一个实例(保证了每个浮层一个实例),在lock变化时调用 lockunlock来解决滚动穿透,使用起来就非常简单了:

<ScrollFix lock={show}>
   <!-- 浮层内容 -->
</ScrollFix>

只需要将浮层包裹在组件内,并且传入 lock属性,即可不用再关注滚动穿透的问题。

版权声明:龙喵网!!!网站网址:http://ailongmiao.com

来源:IMWeb前端社区

1.部分文章来自网络,如有侵犯权益,请联络博主,资源失效与内容勘误留言说明.

2.如若转载,请注明出处:http://ailongmiao.com/read/529.html

[ web前端导航 ]:http://ailongmiao.com/web/

相关阅读

    评论

    继续阅读

    细数CSS伪元素及其用法

    Web前端 2019-03-29 8

    CSS中有两个很常见的概念,伪类和伪元素。伪类用于在页面中的元素处于某个状态时,为其添加指定的样式。伪元素会创建一个抽象的伪元

      选择打赏方式

    打赏

    打赏