【转载】Web移动端Fixed布局的解决方案

特别声明:本文转载于EFE的《Web移动端Fixed布局的解决方案》。如需转载,烦请注明原文出处:http://efe.baidu.com/blog/mobile-fixed-layout

移动端业务开发,iOS 下经常会有 fixed 元素和输入框(input 元素)同时存在的情况。 但是 fixed 元素在有软键盘唤起的情况下,会出现许多莫名其妙的问题。 这篇文章里就提供一个简单的有输入框情况下的 fixed 布局方案。

iOS下的 Fixed + Input BUG现象

让我们先举个栗子,最直观的说明一下这个 BUG 的现象。 常规的 fixed 布局,可能使用如下布局(以下仅示意代码):

<body class="layout-fixed">
    <!-- fixed定位的头部 -->
    <header>

    </header>

    <!-- 可以滚动的区域 -->
    <main>
        <!-- 内容在这里... -->
    </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 {
    margin-top: 50px;
    margin-bottom: 34px;
    height: 2000px
}

然后看起来就是下面这个样子。拖动页面时 header 和 footer 已经定位在了对应的位置,目测没问题了。

但接下来问题就来了!如果底部输入框软键盘被唤起以后,再次滑动页面,就会看到如下图所示:

我们看到 fixed 定位好的元素跟随页面滚动了起来… fixed 属性失效了!

这是为什么呢?简单解释下: ** 软键盘唤起后,页面的fixed 元素将失效(即无法浮动,也可以理解为变成了absolute定位),所以当页面超过一屏且滚动时,失效的 fixed 元素就会跟随滚动了**。

这便是 iOS 上 fixed 元素和输入框的 bug 。其中不仅限于 type=text 的输入框,凡是软键盘(比如时间日期选择、select 选择等等)被唤起,都会遇到同样地问题。

虽然 iScroll.js 可以很好的解决 fixed 定位滚动的问题,但是不在万不得已的情况下,我们尽量尝试一下不依赖第三方库的布局方案,以简化实现方式。这里抛砖引玉作为参考。

解决思路:

既然在 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>

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: 2000px;
}

这样再来看一下:

在原始输入法下, 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 布局就完成了。

Android 下布局

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

在 Android2.3+ 中,因为不支持 overflow-scrolling,因此部分浏览器内滚动会有不流畅的卡顿。但是目前发现在 body上的滚动还是很流畅的,因此使用第一种在 iOS 出现问题的 fixed 定位的布局就可以了。

如果需要考虑 Android2.3 以下系统,因为不支持 fixed 元素,所以依然要需要考虑使用 iScroll.js 来实现内部滚动。

其实在 fixed 和输入框的问题上,基本思路就是: 由于 fixed 在软键盘唤起后会失效,导致在页面可以滚动时,会跟随页面一起滚动。因此如果页面无法滚动,那么 fixed 元素即使失效,也不会滚动,也就不会出现 bug 了。

所以可以在这个方面去考虑解决问题。

其他的一些细节处理

在细节处理上,其实还有很多要注意的,挑几个实际遇到比较大的问题来说一下:

  • 有时候输入框 focus 以后,会出现软键盘遮挡输入框的情况,这时候可以尝试 input 元素的 scrollIntoView 进行修复。
  • 在 iOS 下使用第三方输入法时,输入法在唤起经常会盖住输入框,只有在输入了一条文字后,输入框才会浮出。目前也不知道有什么好的办法能让唤起输入框时正确显示。这暂时算是 iOS 下的一个坑吧。
  • 有些第三方浏览器底部的工具栏是浮在页面之上的,因此底部 fixed 定位会被工具栏遮挡。解决办法也比较简单粗暴——适配不同的浏览器,调整 fixed 元素距离底部的距离。
  • 最好将 header 和 footer 元素的 touchmove 事件禁止,以防止滚动在上面触发了部分浏览器全屏模式切换,而导致顶部地址栏和底部工具栏遮挡住 header 和 footer 元素。
  • 在页面滚动到上下边缘的时候,如果继续拖拽会将整个 View 一起拖拽走,导致页面的“露底”。

为了防止页面露底,可以在页面拖拽到边缘的时候,通过判断拖拽方向以及是否为边缘来阻止 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);
        }
    }
});
时间: 2024-10-03 13:39:52

【转载】Web移动端Fixed布局的解决方案的相关文章

Web移动端Fixed布局的解决方案

转载于EFE博客,这是一篇非常有价值的文章,做移动端基本跑不了会遇到这篇文章提到的问题. 移动端业务开发,iOS 下经常会有 fixed 元素和输入框(input 元素)同时存在的情况. 但是 fixed 元素在有软键盘唤起的情况下,会出现许多莫名其妙的问题. 这篇文章里就提供一个简单的有输入框情况下的 fixed 布局方案. iOS下的 Fixed + Input BUG现象 让我们先举个栗子,最直观的说明一下这个 BUG 的现象. 常规的 fixed 布局,可能使用如下布局(以下仅示意代码)

[转] Web移动端Fixed布局的解决方案

移动端业务开发,iOS 下经常会有 fixed 元素和输入框(input 元素)同时存在的情况. 但是 fixed 元素在有软键盘唤起的情况下,会出现许多莫名其妙的问题. 这篇文章里就提供一个简单的有输入框情况下的 fixed 布局方案. iOS下的 Fixed + Input BUG现象 让我们先举个栗子,最直观的说明一下这个 BUG 的现象. 常规的 fixed 布局,可能使用如下布局(以下仅示意代码): <body class="layout-fixed"> <

Web移动端Fixed布局的解决方案(原文出处:http://efe.baidu.com/blog/mobile-fixed-layout)

移动端业务开发,iOS 下经常会有 fixed 元素和输入框(input 元素)同时存在的情况. 但是 fixed 元素在有软键盘唤起的情况下,会出现许多莫名其妙的问题. 这篇文章里就提供一个简单的有输入框情况下的 fixed 布局方案. iOS下的 Fixed + Input BUG现象 让我们先举个栗子,最直观的说明一下这个 BUG 的现象. 常规的 fixed 布局,可能使用如下布局(以下仅示意代码): <body class="layout-fixed"> <

虚拟键盘冲击移动端fixed布局的解决方案

在做移动端业务开发时,会碰到fixed元素和输入框同时存在的情况.在手机软键盘唤起的情况下,会造成原本fixed定位的元素跟随软键盘而上浮,对整体布局造成冲击.来看这样一个栗子直观的感受一下这个bug. 问题描述: 开发一个创业板转签页面,预期效果图是这样的. 红色矩形区域为使用fixed布局的内容,其css代码为{width:100%;position:fixed;bottom:0;left:0},这看起来并没有什么问题,但在手机软键盘唤起进行输入的时候,红色矩形区域跟随软键盘而浮动起来,这时

web移动端fixed布局和input等表单的爱恨情仇 - 终极BUG,完美解决

[问题]移动端开发,ios下当fixed属性和输入框input(这里不限于input,只要可以调用移动端输入法的都包括,如:textarea.HTML5中contenteditable等),同时存在的时候:两位大侠瞬间发生剧烈的化学反应,出现各种奇葩问题,见下图: [结论]输入框position属性值不是fixed,而变成了absolute [出现情况]当我们唤起键盘的时候,输入框位置不再页面最下面,或者说页面当时还可以继续往下滚动,再或者页面没有滚动到最下边,这个时候就会出现上面的问题 [学习

从web移动端布局到react native布局

在web移动端通常会有这样的需求,实现上中下三栏布局(上下导航栏位置固定,中间部分内容超出可滚动),如下图所示: 实现方法如下: HTML结构: <div class='container'> <div class='header'></div> <div class='content'></div> <div class='footer'></div> </div> 首先可以利用fixed或者absolute

移动端input获取焦点弹出输入框时影响fixed布局的问题

最近在做移动端项目的时候遇到的一个问题,在点击input获取焦点弹出输入框进行输入后,再次点击input输入框时,意外的事情发生了, 页面突然跳转到确定按钮跳转的页面了,刚开始以为是点击穿透导致的,朝着这个方向一直没有等到解决... 经过反复研究,发现第二次点击input 时,上面有一个隐形的按钮,这是怎么回事,确定按钮怎么就跑到上面去了呢,原来是由于最外层 使用了fixed布局,而第一次点击input获取焦点时,移动端默认弹出的输入框会将fixed布局的元素顶上去. 解决办法: 1.如果使用的

关于web移动端返回到顶部的解决方案

在pc上我们很容易就可以用scrollTop()来实现流程的向上滚动的返回到顶部的动画,然后用到web移动端却没什么卵用,会出现滚动不流畅,卡顿,失灵等等现象. 这是因为移动端的scroll事件触发不频繁,有可能检测不到有<=0的情况 为此,移动端判断次数好些, 下面是具体实现代码,兼容pc: //返回顶部动画 //goTop(500);//500ms内滚回顶部 function goTop(times){  if(!!!times){   $(window).scrollTop(0);   r

web前端响应式布局,自适应全部分辨率

写phpd的我. 近期公司要弄个app关键是没有web开发,而我有比較闲,那就扛枪上阵吧. 响应式布局,web端的?php我一直都是用tp框架,对于web首先想到的是bootstrap框架.仅仅是简单了解过,没真正实践啊.bootstrap比我想象的要好用的多.关键是.关键来了-- app端是仅仅有手机的,pc基本上木有.那就是说仅仅能依照手机端开发,那么boostrap响应式布局就不适用于app了(反正我是做了一套半成品,被推翻了).不能愉快的工作了.好不淡定的时间. .百度.百又问问同事.发