摘要:場景當(dāng)頁面出現(xiàn)浮層的時(shí)候,滑動(dòng)浮層的內(nèi)容,正常情況下預(yù)期應(yīng)該是浮層下邊的內(nèi)容不會(huì)滾動(dòng)然而事實(shí)并非如此。當(dāng)屬性的值為的時(shí)候,代表該監(jiān)聽器內(nèi)部不會(huì)調(diào)用函數(shù)來阻止默認(rèn)滑動(dòng)行為,瀏覽器稱這類型的監(jiān)聽器為被動(dòng)監(jiān)聽器。
場景
當(dāng)頁面出現(xiàn)浮層的時(shí)候,滑動(dòng)浮層的內(nèi)容,正常情況下預(yù)期應(yīng)該是浮層下邊的內(nèi)容不會(huì)滾動(dòng);然而事實(shí)并非如此。
如圖所示,浮層下邊的內(nèi)容并沒有如想象中不受影響。
先去github上搜索一番,發(fā)現(xiàn)有解決此問題的開源包,簡單粗暴直接挑選了其中star的最高的(body-scroll-lock)操作一番!
使用后發(fā)現(xiàn)有一些問題:
安卓端全掛
ios端偶爾會(huì)有鎖不住的情況
查源碼發(fā)現(xiàn)該包在iOS端使用禁止touchmove的方式多帶帶處理,但是在其他端只是給body加overflow: hidden簡單處理。
于是決定寫一個(gè)針對多端通用的包來處理類似的問題。
看到下邊的滾動(dòng)肯定立刻就想到了是整個(gè)viewport的滾動(dòng),那么如果給body設(shè)置overflow: hidden,此時(shí)body的內(nèi)容就只有一屏了,肯定不會(huì)滾動(dòng)了;
body { overflow: hidden; }
此方案在pc端完美解決了我們的問題,然而事情并沒有那么簡單;
再試試移動(dòng)端:
移動(dòng)端中并沒有出現(xiàn)期待的效果。。。
既然pc端已經(jīng)有了完美的方案,下邊我們繼續(xù)探索移動(dòng)端的解決方案。
上邊想到給body設(shè)置overflow: hidden在移動(dòng)端并不能解決我們的問題,是否在于body的height沒有設(shè)置
將html、body的高度都設(shè)置為100%;
給body設(shè)置絕對定位(fixed);
同時(shí)使用這兩個(gè)操作似乎完美滿足了我們的需求;
但是如圖所示,每次都會(huì)將頁面拉到最頂上的位置,這樣看起來又不完美了;
既然使用了定位,那么給一個(gè)top值不就定位到我們想要的位置了(聰明如我)。
tips: body 設(shè)置 relative 定位會(huì)頁面自身拉上去,下邊留白
多次實(shí)驗(yàn)發(fā)現(xiàn)這個(gè)方案在android端中完美達(dá)到了我們想要的結(jié)果,但是在ios端并不理想;每次定位的時(shí)候會(huì)有閃動(dòng)的問題;好事多磨,接著探索ios端的方案。
探索三:禁止touchmove如果禁止掉頁面的touchmove是否可行呢?話不多說就是干!
當(dāng)彈出浮層的時(shí)候禁掉頁面元素的touchmove
document.addEventListener("touchmove", function (event) { event.preventDefault() })
測試發(fā)現(xiàn)沒有達(dá)到想象中的效果,感覺這個(gè)結(jié)果并不能接受啊,禁止document 的touchmove都不能禁止?jié)L動(dòng)的嗎?
進(jìn)一步的探索后發(fā)現(xiàn)原因竟是這個(gè)屬性
passive addEventListener第三個(gè)參數(shù)中傳入
原來是瀏覽器做的一些優(yōu)化,chrome passive-event-listeners
Passive Event Listeners是Chrome提出的一個(gè)新的瀏覽器特性:Web開發(fā)者通過一個(gè)新的屬性passive來告訴瀏覽器,當(dāng)前頁面內(nèi)注冊的事件監(jiān)聽器內(nèi)部是否會(huì)調(diào)用preventDefault函數(shù)來阻止事件的默認(rèn)行為,以便瀏覽器根據(jù)這個(gè)信息更好地做出決策來優(yōu)化頁面性能。當(dāng)屬性passive的值為true的時(shí)候,代表該監(jiān)聽器內(nèi)部不會(huì)調(diào)用preventDefault函數(shù)來阻止默認(rèn)滑動(dòng)行為,Chrome瀏覽器稱這類型的監(jiān)聽器為被動(dòng)(passive)監(jiān)聽器。
知道問題就好說了,給addEventListener傳入第三個(gè)參數(shù)
document.addEventListener("touchmove", function (event) { event.preventDefault() }, { passive: false })
大功告成!
突然想到,如果浮層中還需要滾動(dòng)那就不GG了!
so,是不是可以有選擇性的禁止?jié)L動(dòng)(在浮層中元素滾動(dòng)到最頂部或者最底部之后禁止?jié)L動(dòng))。
多帶帶處理浮層中需要滾動(dòng)的元素;
targetElement.ontouchmove = function (event) { const clientY = event.targetTouches[0].clientY - initialClientY if (targetElement && targetElement.scrollTop === 0 && clientY > 0) { return preventDefault(event) } if (targetElement && (targetElement.scrollHeight - 1 - targetElement.scrollTop <= targetElement.clientHeight) && clientY < 0) { return preventDefault(event) } event.stopPropagation() return true }
這個(gè)方案在ios中完美實(shí)現(xiàn),但是在 android中還是有一點(diǎn)問題;浮層內(nèi)容拉到最頂部或者最底部的時(shí)候依然會(huì)帶動(dòng)頁面的內(nèi)容有一定程度的移動(dòng)。
終極方案來啦!
tua-body-scroll-lock即是在ios、android和PC各個(gè)端多帶帶處理,保證在每個(gè)端都可以實(shí)現(xiàn)完美的效果!
demo
安裝$ npm i -S tua-body-scroll-lock # OR $ yarn add tua-body-scroll-lock使用
import { lock, unlock } from "tua-body-scroll-lock" // 禁止滑動(dòng)后還需要內(nèi)部可以滾動(dòng)的元素(針對移動(dòng)端ios處理) const targetElement = document.querySelector("#someElementId"); lock(targetElement) unlock(targetElement)
tips: PC端不需要targetElement, 不傳targetElement也不想要控制臺(tái)提示可以傳null
import { lock, unlock } from "tua-body-scroll-lock" lock() unlock()
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/103754.html
摘要:場景當(dāng)頁面出現(xiàn)浮層的時(shí)候,滑動(dòng)浮層的內(nèi)容,正常情況下預(yù)期應(yīng)該是浮層下邊的內(nèi)容不會(huì)滾動(dòng)然而事實(shí)并非如此。當(dāng)屬性的值為的時(shí)候,代表該監(jiān)聽器內(nèi)部不會(huì)調(diào)用函數(shù)來阻止默認(rèn)滑動(dòng)行為,瀏覽器稱這類型的監(jiān)聽器為被動(dòng)監(jiān)聽器。 場景 當(dāng)頁面出現(xiàn)浮層的時(shí)候,滑動(dòng)浮層的內(nèi)容,正常情況下預(yù)期應(yīng)該是浮層下邊的內(nèi)容不會(huì)滾動(dòng);然而事實(shí)并非如此。showImg(https://user-gold-cdn.xitu.io...
摘要:接下就說下我對滾動(dòng)穿透問題解決方案探索的過程,希望對大家有點(diǎn)啟發(fā)。心想來了突然意識到寫彈窗的時(shí)候忘記處理滾動(dòng)穿透的問題了。下期預(yù)告前端詞典繼承必懂知識點(diǎn)傳送門前端詞典代理的概念及其應(yīng)用前端詞典滾動(dòng)穿透問題的解決方案 背景 產(chǎn)品有三寶,彈窗,浮層加引導(dǎo); 設(shè)計(jì)有三寶,透明,陰影加圓角; 運(yùn)營有三寶,短信,推送加紅包; 程序員有一寶,這個(gè)做不了。 隨著移動(dòng)端市場的份額越大,需求就越多...
摘要:接下就說下我對滾動(dòng)穿透問題解決方案探索的過程,希望對大家有點(diǎn)啟發(fā)。心想來了突然意識到寫彈窗的時(shí)候忘記處理滾動(dòng)穿透的問題了。下期預(yù)告前端詞典繼承必懂知識點(diǎn)傳送門前端詞典代理的概念及其應(yīng)用前端詞典滾動(dòng)穿透問題的解決方案 背景 產(chǎn)品有三寶,彈窗,浮層加引導(dǎo); 設(shè)計(jì)有三寶,透明,陰影加圓角; 運(yùn)營有三寶,短信,推送加紅包; 程序員有一寶,這個(gè)做不了。 隨著移動(dòng)端市場的份額越大,需求就越多...
摘要:問題眾所周知,移動(dòng)端當(dāng)有遮罩背景和彈出層時(shí),在屏幕上滑動(dòng)能夠滑動(dòng)背景下面的內(nèi)容,這就是著名的滾動(dòng)穿透問題之前搜索了一圈,找到下面兩種方案之頁面彈出層上將添加到上,禁用和的滾動(dòng)條但是這個(gè)方案有兩個(gè)缺點(diǎn)由于和的滾動(dòng)條都被禁用,彈出層 問題 眾所周知,移動(dòng)端當(dāng)有 fixed 遮罩背景和彈出層時(shí),在屏幕上滑動(dòng)能夠滑動(dòng)背景下面的內(nèi)容,這就是著名的滾動(dòng)穿透問題 之前搜索了一圈,找到下面兩種方案 c...
摘要:所以這種情況下是不符合點(diǎn)擊事件的定義的。,關(guān)于移動(dòng)端的點(diǎn)擊事件總結(jié)完了,可能你都沒想到一個(gè)簡單的點(diǎn)擊事件會(huì)有那么多坑,如果你在工作中可能會(huì)涉及到移動(dòng)端開發(fā)的話,相信這篇文章還是值得你點(diǎn)贊和收藏的,畢竟是踩了那么多坑的經(jīng)驗(yàn)總結(jié)。 看標(biāo)題的時(shí)候你可能會(huì)想,點(diǎn)擊事件有什么好說的,還寫一篇攻略?哈哈,如果你這么想,只能說明你too young to simple. 接觸過移動(dòng)端開發(fā)的同學(xué)可能都...
閱讀 1210·2021-11-24 11:16
閱讀 3438·2021-11-15 11:38
閱讀 1943·2021-10-20 13:47
閱讀 556·2021-09-29 09:35
閱讀 2206·2021-09-22 15:17
閱讀 1022·2021-09-07 09:59
閱讀 3392·2019-08-30 13:21
閱讀 2915·2019-08-30 12:47