移動端業務開發,iOS 下常常會有 fixed 元素和輸入框(input 元素)同時存在的狀況。 可是 fixed 元素在有軟鍵盤喚起的狀況下,會出現許多莫名其妙的問題。 這篇文章裏就提供一個簡單的有輸入框狀況下的 fixed 佈局方案。javascript
讓咱們先舉個栗子,最直觀的說明一下這個 BUG 的現象。 常規的 fixed 佈局,可能使用以下佈局(如下僅示意代碼):css
<body class="layout-fixed"> <!-- fixed定位的頭部 --> <header> </header> <!-- 能夠滾動的區域 --> <main> <!-- 內容在這裏... --> </main> <!-- fixed定位的底部 --> <footer> <input type="text" placeholder="Footer..."/> <button class="submit">提交</button> </footer> </body>
對應的樣式以下:java
header, footer, main { display: block; } header { position: fixed; height: 50px; left: 0; right: 0; top: 0; } footer { position: fixed; height: 34px; left: 0; right: 0; bottom: 0; } main { margin-top: 50px; margin-bottom: 34px; height: 2000px }
而後看起來就是下面這個樣子。拖動頁面時 header 和 footer 已經定位在了對應的位置,目測沒問題了。web
fixed定位瀏覽器
但接下來問題就來了!若是底部輸入框軟鍵盤被喚起之後,再次滑動頁面,就會看到以下圖所示:工具
咱們看到 fixed 定位好的元素跟隨頁面滾動了起來… fixed 屬性失效了!佈局
這是爲何呢?簡單解釋下: > 軟鍵盤喚起後,頁面的 fixed 元素將失效(即沒法浮動,也能夠理解爲變成了 absolute 定位),因此當頁面超過一屏且滾動時,失效的 fixed 元素就會跟隨滾動了。測試
這即是 iOS 上 fixed 元素和輸入框的 bug 。其中不只限於 type=text
的輸入框,凡是軟鍵盤(好比時間日期選擇、select 選擇等等)被喚起,都會遇到一樣地問題。ui
雖然 isScroll.js
能夠很好的解決 fixed 定位滾動的問題,可是不在萬不得已的狀況下,咱們儘可能嘗試一下不依賴第三方庫的佈局方案,以簡化實現方式。這裏拋磚引玉做爲參考。this
既然在 iOS 下因爲軟鍵盤喚出後,頁面 fixed 元素會失效,致使跟隨頁面一塊兒滾動,那麼 假如——頁面不會過長出現滾動,那麼即使 fixed 元素失效,也沒法跟隨頁面滾動,也就不會出現上面的問題了 。
那麼按照這個思路,若是使 fixed 元素的父級不出現滾動,而將原 body 滾動的區域域移到 main 內部,而 header 和 footer 的樣式不變,代碼以下:
<body class="layout-scroll-fixed"> <!-- fixed定位的頭部 --> <header> </header> <!-- 能夠滾動的區域 --> <main> <div class="content"> <!-- 內容在這裏... --> </div> </main> <!-- fixed定位的底部 --> <footer> <input type="text" placeholder="Footer..."/> <button class="submit">提交</button> </footer> </body>
header, footer, main { display: block; } header { position: fixed; height: 50px; left: 0; right: 0; top: 0; } footer { position: fixed; height: 34px; left: 0; right: 0; bottom: 0; } main { /* main絕對定位,進行內部滾動 */ position: absolute; top: 50px; bottom: 34px; /* 使之能夠滾動 */ overflow-y: scroll; } main .content { height: 2000px; }
這樣再來看一下:
fixed定位
在原始輸入法下, fixed 元素能夠定位在頁面的正確位置。滾動頁面時,因爲滾動的是 main 內部的 div,所以 footer 沒有跟隨頁面滾動。
上面貌似解決了問題,可是若是在手機上實際測試一下,會發現 main 元素內的滾動很是不流暢,滑動的手指鬆開後,滾動馬上中止,失去了本來的流暢滾動特性。百度一下彈性滾動的問題,發如今 webkit
中,下面的屬性能夠恢復彈性滾動。
-webkit-overflow-scrolling: touch;
在 main 元素上加上該屬性,嗯,絲般順滑的感受又回來了!
main { /* main絕對定位,進行內部滾動 */ position: absolute; top: 50px; bottom: 34px; /* 使之能夠滾動 */ overflow-y: scroll; /* 增長該屬性,能夠增長彈性 */ -webkit-overflow-scrolling: touch; }
另外,這裏的 header 和 footer 使用的是 fixed 定位,若是考慮到更老一些的 iOS 系統不支持 fixed 元素,徹底能夠把 fixed 替換成 absolute 。測試後效果是同樣的。
至此一個不依賴第三方庫的 fixed 佈局就完成了。
談到了 iOS ,也來簡單說一下 Android 下的佈局吧。
在 Android2.3+ 中,由於不支持 overflow-scrolling ,所以部分瀏覽器內滾動會有不流暢的卡頓。可是目前發如今 body 上的滾動仍是很流暢的,所以使用第一種在 iOS 出現問題的 fixed 定位的佈局就能夠了。
若是須要考慮 Android2.3 如下系統,由於不支持 fixed 元素,因此依然要須要考慮使用 isScroll.js
來實現內部滾動。
其實在 fixed 和輸入框的問題上,基本思路就是: > 因爲 fixed 在軟鍵盤喚起後會失效,致使在頁面能夠滾動時,會跟隨頁面一塊兒滾動。所以若是頁面沒法滾動,那麼 fixed 元素即便失效,也不會滾動,也就不會出現 bug 了。
因此能夠在這個方面去考慮解決問題。
在細節處理上,其實還有不少要注意的,挑幾個實際遇到比較大的問題來講一下:
在頁面滾動到上下邊緣的時候,若是繼續拖拽會將整個 View 一塊兒拖拽走,致使頁面的「露底」。
fixed定位
爲了防止頁面露底,能夠在頁面拖拽到邊緣的時候,經過判斷拖拽方向以及是否爲邊緣來阻止 touchmove 事件,防止頁面繼續拖拽。
以上面內滾動 layout-scroll-fixed
佈局爲例,給出一段代碼做爲參考:
// 防止內容區域滾到底後引發頁面總體的滾動 var content = document.querySelector('main'); var startY; content.addEventListener('touchstart', function (e) { startY = e.touches[0].clientY; }); content.addEventListener('touchmove', function (e) { // 高位表示向上滾動 // 底位表示向下滾動 // 1允許 0禁止 var status = '11'; var ele = this; var currentY = e.touches[0].clientY; if (ele.scrollTop === 0) { // 若是內容小於容器則同時禁止上下滾動 status = ele.offsetHeight >= ele.scrollHeight ? '00' : '01'; } else if (ele.scrollTop + ele.offsetHeight >= ele.scrollHeight) { // 已經滾到底部了只能向上滾動 status = '10'; } if (status != '11') { // 判斷當前的滾動方向 var direction = currentY - startY > 0 ? '10' : '01'; // 操做方向和當前容許狀態求與運算,運算結果爲0,就說明不容許該方向滾動,則禁止默認事件,阻止滾動 if (!(parseInt(status, 2) & parseInt(direction, 2))) { stopEvent(e); } } });