这是一个存在很久的历史问题了，对付这样一个具有遍及性的问题浏览器偏偏没有给出解决方案，what？没有方案还聊个什么？

别急，别急，接下来我们一起来扒一扒关于软键盘高度和 input 的问题

我们先来看一个短片认识一下这个问题

问题描述：当操纵者进行输入操纵的时候，弹起的软键盘把原本的输入框遮挡了，导致操纵者看不到操纵功效

以往的解决方案：

改削网站的页面构造，好比本例中 twitter 尽量把 input 安排在中部以上的位置，从构造上尽量制止此类问题

在一些指定设备和浏览器中异步获取 window.innerHeight 进行前后比拟而得出键盘高度

再来看一下另一种常见输入框的页面构造：

在这个场景里，输入框定位在页面的最底部，当软键盘弹起时整个视图窗口页面向上卷动，达到最底部时遏制。刚巧当我们用 h5 来模拟这个效果的时候恰好勉强做到。

这是因为当你初度 fouse 到输入框的时候软键盘弹出，浏览器会使页面会向上滚动，以确保 input 是可见的，该特性和 document.body.scrollIntoViewIfNeeded 要领是一致的，但是当你 body 的可滚动高度赶过窗口高度时还会孕育产生另一个问题：固定元素将随页面滚动 如下图

因此浏览器关心的只是 input 是否被笼罩？实际上是 input 中的光标位置！那么这就解释了为什么输入框在底部的时候恰好勉强完成了，因为 input 在页面的底部时，软键盘弹出势必会遮盖住 input，因而浏览器会向上滚动至输入框可见的位置。

但是如下图的效果这样就无法做到了，因为在输入框的下面还有一行工具栏，也就是说输入框并非在最底部的位置，那么浏览器在滚动到可视位置时只会确保到 input 可见，而对付工具栏是否可见则并不在浏览器的考虑范畴内。

综合来看上面两种构造方案的问题，都不能完美解决输入被键盘遮挡和底部 footer 不能被顶起的问题，那是不是就没得办法了？

固然号称可以让 HTML5 表示更接近 Native 的 IOING 引擎必然是有解决方案的

我们先来看一段 input 在 IOING 中的表示

我们可以看到在输入过程中页面通过滚动来始终连结光标位于可视区域的中心位置，因此在这里我们需要提一个常识点：获取输入光标的实时位置，固然这也是一个曲折的过程，在这里我就不扩算话题了，继续来讲原话题

前面说了三个主要的传统解决方案：

第一个是通过把 input 构造尽量放在页面顶部，显然这个不是我们想要的，反对失

把 input 放在最底部，用来完成 footer 固定的效果，但是要局限页面高度不赶过窗口高度，我们可以通过便宜滚动控件来解除这个限制，那此刻需要解决的技术点就变为实现一个模拟滚动控件