[Go] solution for fixed layout of web mobile

Mobile business development, under IOS often have fixed elements and input boxes (input elements) exist at the same time. However, fixed elements in the case of a soft keyboard aroused, there will be a lot of inexplicable problems. This article provides a simple fixed layout scheme with input boxes.

Fixed + Input bug phenomenon under iOS

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

<Bodyclass="Layout-fixed" > <!--fixed-positioned head-to- <Header> </Header> <!--areas that can be scrolled-- <Main> <!--content here ...- </MAIN> <!--fixed positioning of the bottom--> << Span class= "title" >FOOTER> <input type=" text "placeholder=" Footer ... "/ <button class= "submit" > Submit </BUTTON> </FOOTER> </ BODY>

The corresponding styles are as follows:

HeaderFooterMain{ DisplayBlock } Header{ PositionFixed Height 50px; Left 0; Right 0; Top 0; } Footer{ PositionFixed Height 34px; Left 0; right: 0 ; bottom: 0; } main { margin-top: 50px; margin-bottom: 34PX; height: 2000px

And then it looks like the following. When you drag the page header and footer have been positioned in the corresponding position, visual no problem.

Fixed positioning

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 positioned elements following the page scrolling ... the fixed property is invalid!

What is this for? Simple explanation: After the > soft Keyboard is aroused, the fixed element of the page will be invalidated (that is, it cannot be floated or it can be understood as absolute positioning), so when the page is more than one screen and scrolling, the invalid fixed element will follow the scroll.

This is the fixed element and input box bug 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 isScroll.js it can be a good solution to the fixed positioning scrolling problem, but not a 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 fixed element will fail after the soft keyboard is called under IOS, which causes the page to scroll along with the pages, if the page does not scroll too long, then even if the fixed element fails, it will not be able to follow the page scrolling, and the above problem won't occur .

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

<Bodyclass="Layout-scroll-fixed" > <!--fixed-positioned head-to- <Header> </Header> <!--areas that can be scrolled-- <Main> <Divclass="Content" > <!--content here ...- </Div> </MAIN> <!--fixed positioning of the bottom--> << Span class= "title" >FOOTER> <input type=" text "placeholder=" Footer ... "/ <button class= "submit" > Submit </BUTTON> </FOOTER> </ BODY>

HeaderFooterMain{ DisplayBlock } Header{ PositionFixed Height 50px; Left 0; Right 0; Top 0; } Footer{ PositionFixed Height 34px; Left 0; Right 0; Bottom 0; } Main{ /* Main is absolutely positioned for internal scrolling */ Position absolute; top: 50px; bottom: 34px; /* so that it can scroll */ overflow-y: scroll; } main Span class= "class" >.content { height: 2000px; } /span>

So look again:

Fixed positioning

Under the original input method, the fixed element can be positioned in the correct position on the page. When scrolling the page, the footer does not follow the page scrolling because it scrolls through the div inside main.

The above seems to solve the problem, but if the actual test on the phone, you will find the main element 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;

Add this property to the main element, and the silky smooth feel is back!

Main{ /* main absolute positioning, internal scrolling */ absolute; top: 50px; bottom: 34px; /* so that it can scroll */ overflow-y: scroll; /* add this property, you can increase the elasticity */ -webkit-overflow-scrolling: touch; } /span>

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

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

Android under Layout

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

In android2.3+, because overflow-scrolling is not supported, there is a non-smooth lag in some browser scrolling. But now the scroll on the body has been found to be smooth, so use the first fixed-positioning layout that has problems with IOS.

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

In fact, the fixed and input frame of the problem, the basic idea is: > because the fixed on the soft keyboard after the invalidation, resulting in the page can scroll, will follow the page along with scrolling. 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:

1. Sometimes after the input box focus, there will be soft keyboard occlusion input box, this time you can try the INPUT element scrollIntoView to repair.
2. 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.
3. Some third-party browsers have toolbars floating on top of the page, so the bottom fixed positioning is obscured by the toolbar. The solution is also relatively simple and rough--adapting different browsers to adjust the distance from the bottom of the fixed element.
4. It is best to disallow the Touchmove event of the header and footer elements to prevent scrolling from triggering a partial browser full-screen mode switch, which causes the top address bar and the bottom toolbar to block the header and footer elements.

5. 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.

   Fixed positioning

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 and dragged to the edge.

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 over var content =Document.queryselector (' main '); var starty; 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 var status =' 11 '; var ele =This var currenty = e.touches[0].clienty; if (ele.scrolltop = = =0) { Disable scrolling up and down if content is smaller than the container Status = Ele.offsetheight >= ele.scrollheight?' 00 ':' 01 '; }Elseif (ele.scrolltop + ele.offsetheight >= ele.scrollheight) { It's already rolled to the bottom. Scroll up only if (status! = //determine the current scrolling direction var direction = currenty-starty > 0? //the operation direction and the current allowable state and operation, the result of the operation is 0, indicating that the direction is not allowed to scroll, the default event is suppressed, the is prevented from scrolling. if (! ( parseint (status, 2) & parseint (direction, Span class= "number" >2)) { Stopevent (e);

[Go] solution for fixed layout of web mobile