Let's take a look at an article about CSS-webkit-overflow-scrolling:touch manual change scrolltop caused by bugs and solutions, I hope this solution can help fellow students.
For-webkit-overflow-scrolling, look at the relevant API, which is primarily used to set whether scrolling in the iOS browser's container turns on inertia and resilience.
So, the general situation is to set its value to touch the
-webkit-overflow-scrolling:touch
However, this time a bug was encountered.
My requirement is to manually set the scrolling height, the JS code is
El.scrolltop = 500;
At this point, I found that in the iOS environment, after each manual change scrolltop the entire container into a blank, but the finger touch the content came out, ScrollTop is successfully changed, but the content of the drawing error. (Here I personally judge the bottom of the browser problem, because Android does not exist this problem)
I forced redrawing by delaying the setting of a delay load, or by manually changing the contents of the container, but it did not work, and finally found the problem in-webkit-overflow-scrolling:touch, because the bug did not exist when I set the value to auto.
Thought out, before manually set ScrollTop, first turn off the inertia of scrolling, to be completed after the reset can be opened.
Paste the resolution code:
El. webkitoverflowscrolling = ' auto ';
El.scrolltop = 500;
El. webkitoverflowscrolling = ' touch ';
Check the information on the Internet, H5 end of the code is no longer covered, look at the native processing
The-webkit-overflow-scrolling:touch process is as follows:
In fact, Safari really uses the native control to implement, for the page that has-webkit-overflow-scrolling, will create a uiscrollview, provide the child layer to use to the rendering module
To achieve this effect is simple, just add a line of CSS code to:
[CSS] View plain copy on the code to see a piece of coding derived to my Code slice
-webkit-overflow-scrolling:touch;
The following Web pages are available for testing:
[HTML] View plain copy on the code to see a piece of a snippet derived from my Code
<! DOCTYPE HTML PUBLIC "-//w3c//dtd HTML 4.01 transitional//en" >
<meta charset= "Utf-8"/>
<title>scroll</title>
<style type= "Text/css" >
. container {
width:300px;
height:50%;
-webkit-box-sizing:border-box;
position:relative;
Overflow-y: auto;
Background-color:cyan;
-webkit-overflow-scrolling:touch; /* LIUHX: The whole line can be commented out of the contrast difference * *
}
UL {
height:50px;
}
</style>
<body>
<div align= "center" >
<nav class= "Container" >
<ul>1</ul>
<ul>2</ul>
<ul>3</ul>
<ul>4</ul>
<ul>5</ul>
<ul>6</ul>
<ul>7</ul>
<ul>8</ul>
<ul>9</ul>
<ul>10</ul>
<ul>11</ul>
<ul>12</ul>
<ul>13</ul>
<ul>14</ul>
<ul>15</ul>
<ul>16</ul>
<ul>17</ul>
<ul>18</ul>
<ul>19</ul>
<ul>20</ul>
</nav>
</div>
</body>
You can slide the blue area of the middle with your fingers and you'll find the rebound effect and roll fast:
(Click the picture to see the larger image)
If you comment out the line of-webkit-overflow-scrolling, you will find that scrolling slowly.
In fact, Safari really uses the native control to implement, for the page that has-webkit-overflow-scrolling, will create a uiscrollview, provide the child layer to the rendering module to use. The stack at the time of creation is as follows:
[Plain] View plain copy on the code to see a piece of coding derived to my Code slice
Thread 1, Queue:com.apple.main-thread
#0 0x00086723 in-[uiscrollview initWithFrame:] ()
#1 0x004ec3bd in-[uiweboverflowscrollview InitWithLayer:node:webDocumentView:] ()
#2 0x001f1769 in-[uiwebdocumentview webView:didCreateOrUpdateScrollingLayer:withContentsLayer:scrollSize:forNode: Allowhorizontalscrollbar:allowverticalscrollbar:] ()
#3 0x01d571bd in __invoking___ ()
#4 0x01d570d6 in-[nsinvocation invoke] ()
#5 0x01d5724a in-[nsinvocation Invokewithtarget:] ()
#6 0X027FB6A1 in-[_websafeforwarder forwardinvocation:] ()
#7 0x027fb8ab in __44-[_websafeasyncforwarder forwardinvocation:]_block_invoke_0 ()
#8 0x04ac753f in _dispatch_call_block_and_release ()
#9 0x04ad9014 in _dispatch_client_callout ()
#10 0x04ac97d5 in _DISPATCH_MAIN_QUEUE_CALLBACK_4CF ()
#11 0x01d09af5 in __cfrunlooprun ()
#12 0x01d08f44 in Cfrunlooprunspecific ()
#13 0x01d08e1b in Cfrunloopruninmode ()
#14 0x01cbd7e3 in Gseventrunmodal ()
#15 0x01cbd668 in Gseventrun ()
#16 0X00032FFC in Uiapplicationmain ()
#17 0x00002ae2 in main at/users/liuhx/desktop/uiwebview_research/webviewresearch/main.mm:16
The actual creation is Uiweboverflowscrollview, which inherits from Uiscrollview, declared as:
[CPP] View plain copy on the code to see a piece of coding derived to my Code slice
@class Domnode, Uiwebdocumentview, Uiweboverflowcontentview, Uiweboverflowscrolllistener;
@interface Uiweboverflowscrollview:uiscrollview
{
Uiwebdocumentview *_webdocumentview;
Uiweboverflowscrolllistener *_scrolllistener;
Uiweboverflowcontentview *_overflowcontentview;
Domnode *_node;
BOOL _beingremoved;
}
@property (nonatomic, getter=isbeingremoved) BOOL beingremoved; @synthesize beingremoved=_beingremoved;
@property (Retain, nonatomic) Domnode *node; @synthesize Node=_node;
@property (Retain, nonatomic) Uiweboverflowcontentview *overflowcontentview; @synthesize Overflowcontentview=_overflowcontentview;
@property (Retain, nonatomic) Uiweboverflowscrolllistener *scrolllistener; @synthesize Scrolllistener=_scrolllistener;
@property (nonatomic) Uiwebdocumentview *webdocumentview; @synthesize Webdocumentview=_webdocumentview;
-(void) Setcontentoffset: (struct cgpoint) arg1;
-(void) _replacelayer: (ID) arg1;
-(void) prepareforremoval;
-(void) fixupviewafterinsertion;
-(ID) Superview;
-(void) dealloc;
-(ID) Initwithlayer: (ID) arg1 node: (ID) arg2 Webdocumentview: (ID) arg3;
@end
It also has a child view as Contentview, which is a container for webcore that is actually used as a layer for rendering overflow type content.
Uiweboverflowcontentview's statement is:
[CPP] View plain copy on the code to see a piece of coding derived to my Code slice
@interface Uiweboverflowcontentview:uiview
{
}
-(void) _setcachedsubviews: (ID) arg1;
-(void) _replacelayer: (ID) arg1;
-(void) fixupviewafterinsertion;
-(ID) Superview;
-(ID) Initwithlayer: (ID) arg1;
@end
And then to the bottom with, are calayer operation.
All of the above two classes are implementations of the Uikit layer, requiring webcore support with hardware acceleration to be meaningful, and the related logic is contained in the
Accelerated_compositing
In this macro.
From SVN log, the WebKit 108400 version is supported, so iOS safari should be 5.0. Android only supports over 4.0.
From the front end development point of view, only need to know the CSS properties-webkit-overflow-scrolling is really created with hardware acceleration of the system-level controls, so highly efficient. But this is relatively more memory-intensive, preferably when a very large area of overflow is produced.