手机端业务流程开发设计,iOS 下常常会出现 fixed 元素和输入框(input 元素)另外存有的情况。 可是 fixed 元素在有软键盘勾起的情况下,会出現很多无缘无故的难题。 本文里就出示一个简易的有输入框情况下的 fixed 布局计划方案。

iOS下的 Fixed Input BUG现象

使我们先举个栗子,最形象化的表明一下这一 BUG 的现象。 基本的 fixed 布局,很有可能应用以下布局(下列仅提示编码)

<body> <!-- fixed精准定位的头顶部 --> <header> </header>
 <!-- 能够翻转的地区 --> <main> <!-- 內容在这儿... --> </main> 
<!-- fixed精准定位的底端 --> <footer> 
<input type="text" placeholder="Footer..."/> 
<button>递交</button> </footer></body>
相匹配的款式以下:

随后看上去便是下边这一模样。拖拽网页页面headerfooter 早已精准定位在了相匹配的部位,估测没什么问题了。

Web移动端Fixed布局的解决方案 Fixed web web2.0  第1张

但接下去难题就来了!假如底端输入框软键盘被勾起之后,再度拖动网页页面,便会见到如下图所显示:

Web移动端Fixed布局的解决方案 Fixed web web2.0  第2张 Web移动端Fixed布局的解决方案 Fixed web web2.0  第3张

大家见到 fixed 精准定位好的元素追随网页页面翻转了起來… fixed 特性无效了!

这是为什么呢?简易表述下: ** 软键盘勾起后,网页页面的fixed 元素将无效(即没法波动,还可以了解为变成了absolute精准定位),因此当网页页面超出一屏且翻转时,无效的 fixed 元素便会追随翻转了**。

这就是 iOS 上 fixed 元素和输入框的 bug 。在其中不但仅限于 type=text 的输入框,但凡软键盘(例如时间日期挑选、select 挑选这些)被勾起,都是会碰到一样地难题。

尽管 isScroll.js 能够非常好的处理 fixed 精准定位翻转的难题,可是没有迫不得已的情况下,大家尽可能试着一下不依靠第三方库的布局计划方案,以简单化完成方法。这儿毛遂自荐做为参照。

处理构思:

即然在 iOS 下因为软键盘唤醒后,网页页面 fixed 元素会无效,造成 追随网页页面一起翻转,那麼倘若——网页页面不容易太长出現翻转,那麼就算 fixed 元素无效,也没法追随网页页面翻转,也就不容易出現上边的难题了。

那麼依照这一构思,假如使 fixed 元素的父级不出現翻转,而将原 body 翻转的地区域挪到 main 內部,而 headerfooter 的款式不会改变,编码以下:

<body> <!-- fixed精准定位的头顶部 --> 
<header> </header> 
<!-- 能够翻转的地区 --> <main> 
<div> <!-- 內容在这儿... --> </div>
 </main> <!-- fixed精准定位的底端 -->
 <footer> <input type="text" placeholder="Footer..."/> 
<button>递交</button> </footer></body>

CSS:

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: 2001080x;}

那样再看来一下:

Web移动端Fixed布局的解决方案 Fixed web web2.0  第4张

在初始电脑输入法下, fixed 元素能够精准定位在网页页面的恰当部位。翻转网页页面时,因为翻转的是 main 內部的 div,因而 footer 沒有追随网页页面翻转。

上边好像解决了难题,可是假如在手机上具体测试一下,会发觉 main 元素内的翻转十分不顺畅,拖动的手指头松掉后,翻转马上终止,失去本来的顺畅翻转特点。百度一下延展性翻转的难题,发觉在 webkit 中,下边的特性能够修复延展性翻转。

main 元素上再加上该特性,嗯,丝般丝滑的觉得又回家了!

此外,这儿的 headerfooter 应用的是 fixed 精准定位,假如充分考虑更老一些的 iOS 系统软件不兼容 fixed 元素,彻底能够把 fixed 换成 absolute 。检测后实际效果是一样的。

到此一个不依靠第三方库的 fixed 布局就完成了。

Android 下布局

提到了 iOS ,也来简易说一下 Android 下的布局吧。

在 Android2.3 中,由于不兼容 overflow-scrolling,因而一部分电脑浏览器内翻转会出现不顺畅的卡屏。可是现阶段发觉在 body 上的翻转還是很顺畅的,因而应用第一种在 iOS 出現难题的 fixed 精准定位的布局就可以了。

假如必须考虑到 Android2.3 下列系统软件,由于不兼容 fixed 元素,因此仍然要必须考虑到应用 isScroll.js 来完成內部翻转。

实际上在 fixed 和输入框的难题上,理论依据便是: 因为 fixed 在软键盘勾起后会无效,造成 在网页页面能够翻转时,会追随网页页面一起翻转。因而假如网页页面没法翻转,那麼 fixed 元素即便无效,也不会翻转,也就不容易出現 bug 了。

因此能够在这个层面去考虑到解决困难。

别的的一些关键点解决

在关键点解决上,实际上也有许多要留意的,挑好多个具体碰到较为大的难题而言一下:

有时输入框 focus 之后,会出現软键盘挡住输入框的情况,此刻能够试着 input 元素的 scrollIntoView 开展修补。在 iOS 下应用第三方电脑输入法时,电脑输入法在勾起常常会遮住输入框,仅有在键入了一条文本后,输入框才会浮起。现阶段也不知道有什么好的方法能让勾起输入框时恰当显示信息。这临时算作 iOS 下的一个坑吧。一些第三方电脑浏览器底端的菜单栏是浮在网页页面以上的,因而底端 fixed 精准定位会被菜单栏挡住。解决方案也较为简单直接——兼容不一样的电脑浏览器,调节 fixed 元素间距底端的间距。最好是将 headerfooter 元素的 touchmove 恶性事件严禁,以避免 翻转在上面开启了一部分浏览器全屏方式转换,而造成 顶端地址栏和底端菜单栏遮盖住 headerfooter 元素。在网页页面翻转到左右边沿的情况下,假如再次拖动会将全部 View 一起拖动走,造成 网页页面的“漏底”。

Web移动端Fixed布局的解决方案 Fixed web web2.0  第5张

为了更好地避免 网页页面漏底,能够在网页页面拖动到边沿的情况下,根据分辨拖动方位及其是不是为边沿来阻拦 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); } }});