"Reprint" solution for fixed layout of Web mobile terminal

Special Statement: This article is reproduced in Efe's "Web Mobile terminal fixed layout solution." If you need to reprint, please indicate the original source: Http://efe.baidu.com/blog/mobile-fixed-layout

Mobile business development, under IOS there will often be fixed elements and input boxes ( input elements) exist at the same time. However fixed , there are many puzzling problems in the case that the element is aroused by a soft keyboard. This article provides a simple layout scheme with input boxes fixed .

Fixed + Input bug phenomenon under iOS

Let us first give a chestnut, the most intuitive explanation of the phenomenon of this BUG. The general fixed layout may use the following layout (only the schematic code below):

<Bodyclass= "Layout-fixed">    <!--fixed positioning of the head -    <Header>    </Header>    <!--areas that can be scrolled -    <Main>        <!--the content is here ... -    </Main>    <!--bottom of fixed positioning -    <Footer>        <inputtype= "text"placeholder= "Footer ..."/>        <Buttonclass= "Submit">Submit</Button>    </Footer></Body>

The corresponding styles are as follows:

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}

And then it looks like the following. Drag the page header and footer has been positioned in the corresponding position, visual no problem.

But then the problem comes! If the bottom input box soft keyboard is aroused later, sliding the page again, you will see as shown:

We see fixed the positioned elements following the page scrolling up ... fixed the property is dead!

What is this for? Simple explanation: * * After the soft keyboard is aroused, the elements of the page fixed will be invalidated (i.e. cannot be floated or understood to be absolute positioned), so when the page is more than one screen and scrolling, the invalid fixed element will follow the scroll.

This fixed is a bug in the elements and input boxes on IOS. This is not limited to type=text the input box, usually the soft keyboard (such as time-date selection, select Selection, etc.) are aroused, will encounter the same problem.

Although iScroll.js it can be a good solution to the fixed problem of positioning scrolling, but not the last resort, we try to do not rely on third-party library layout scheme, to simplify the implementation. Here is a reference.

Solution Ideas:

Since the page element will fail after the soft keyboard is called in IOS, and the page is scrolled along with it, fixed if-the page does not scroll too long, then even if the fixed element fails, it cannot follow the page scrolling, and there will be no problem.

So according to this idea, if the fixed parent of the element does not scroll, and body the original scrolling region field is moved main inside, header and footer the style is unchanged, the code is as follows:

<Bodyclass= "Layout-scroll-fixed">    <!--fixed positioning of the head -    <Header>    </Header>    <!--areas that can be scrolled -    <Main>        <Divclass= "Content">        <!--the content is here ... -        </Div>    </Main>    <!--bottom of fixed positioning -    <Footer>        <inputtype= "text"placeholder= "Footer ..."/>        <Buttonclass= "Submit">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 absolute positioning, internal scrolling*/position:Absolute;Top:50px;Bottom:34px;/*so that it can be scrolled*/overflow-y:Scroll;}Main. Content{Height:2000px;}

So look again:

Under the original Input method, the fixed element can be positioned in the correct position on the page. When scrolling the page, the scrolling is main internal div and therefore footer does not follow the page scrolling.

The above seems to solve the problem, but if the actual test on the phone, you will find that main the elements of the scroll is very fluid, the sliding finger released, the scroll immediately stop, lost the original smooth scrolling characteristics. Baidu on the issue of elastic scrolling, found in the webkit following properties can restore elastic scrolling.

-webkit-overflow-scrolling:touch;

mainAdd this attribute to the element, and the silky smooth feel is back!

 main  {/*   */  position : Span style= "color: #0000ff;" > absolute ; :  50px ;     bottom :  34px ; /*   so that it can scroll  */     Overflow-y :  scroll ; /*   increase this property to increase the elasticity  */ -webkit-overflow-scrolling :  touch ;} 

In addition, here header and footer use is fixed positioning, if considering the older IOS system does not support fixed elements, can be fixed replaced completely absolute . The effect is the same after the test.

This is done with a layout that does not rely on a third-party library fixed .

Android under Layout

When it comes to IOS, let's simply talk about the layout of Android.

In android2.3+, because it is not supported overflow-scrolling , there is no smooth lag in some browser scrolling. However, the current body scroll is still very smooth, so use the first layout that has problems with IOS fixed .

If you need to consider Android2.3 the following systems, because elements are not supported fixed , you still need to consider using iScroll.js them for internal scrolling.

In fact fixed , the problem with the input box, the basic idea is: because fixed after the soft keyboard aroused will be invalidated, resulting in the page can scroll, will follow the page scroll together. Therefore, if the page cannot scroll, the fixed element will not scroll if it fails, and there will be no bug.

So you can think about solving the problem in this regard.

Some other details to deal with

In the details of processing, in fact, there are a lot to pay attention to, pick a few actually encountered a larger problem to say:

• Sometimes after the input box focus , there will be soft keyboard occlusion input box situation, this time you can try to input repair the element scrollIntoView .
• When using a third-party input method under IOS, the input input box will often be covered by the input method, and it will only appear when a text is entered. At the moment, I don't know if there is any good way to make the input box appear correctly. This is a temporary pit under IOS.
• Some third-party browsers have toolbars floating on top of the page, so bottom fixed positioning is obscured by toolbars. The solution is also relatively simple and rough--adapting to different browsers, adjusting the fixed distance from the bottom of the element.
• It is best to header footer block and element touchmove events to prevent scrolling on the above triggered partial browser full-screen mode switch, which causes the top address bar and the bottom toolbar to mask header and footer element.
• When scrolling to the top and bottom of the page, dragging and dragging will drag the entire View together, leading to the "threadbare" of the page.

To prevent the page from threadbare, you can prevent the page from dragging and dropping by judging the drag direction and whether it is an edge when the page is dragged to the edge touchmove .

Take the above scrolling layout-scroll-fixed layout as an example and give a piece of code as a reference:

//prevents scrolling of the entire page after the content area rolls overvarContent = Document.queryselector (' main ');varStarty;content.addeventlistener (' Touchstart ',function(e) {starty= E.touches[0].clienty;}); Content.addeventlistener (' Touchmove ',function(e) {//High level means scrolling up    //bottom position indicates scroll down    //1 allowable 0 Forbidden    varStatus = ' 11 '; varEle = This; varCurrentY = E.touches[0].clienty; if(Ele.scrolltop = = 0) {        //disable scrolling up and down if content is smaller than the containerStatus = Ele.offsetheight >= ele.scrollheight? ' 00 ': ' 01 '; } Else if(Ele.scrolltop + ele.offsetheight >=ele.scrollheight) {//It's already rolled to the bottom. Scroll up onlyStatus = ' 10 '; }    if(Status! = ' 11 ') {        //determine the current scrolling direction        varDirection = currenty-starty > 0? ' 10 ': ' 01 '; //operation direction and the current allowable state and operation, the result of the operation is 0, which means that the direction is not allowed to scroll, the default event is suppressed, the scrolling is prevented        if(! (parseint (Status, 2) & parseint (direction, 2)) {stopevent (e); }    }});

"Reprint" solution for fixed layout of Web mobile terminal