This code was working fine on my iphone before updating to iOS 9.0.1 (13A404), but now the same code seems to be working only after finger release, or after the jQuery onscroll ends, when I do a quick swipe leaving the page scrolling...
$(document).on('scroll', function(){
if( $(this).scrollTop() > 0){
$('.menu').addClass('sticky');
}else{
$('.menu').removeClass('sticky');
}
});
The sticky menu just disappears until I release the finger up from the screen, losing the "stickying" effect in realtime during the swipe that I had before in all my websites and that are now broken...
How can solve this problem making them working like I had before? (smooth sticky in realtime)
After observing the same behaviour and testing around a bit, the simplest way is to activate 3D transforms as proposed in a similar question:
.sticky-element {
-webkit-transform: translate3d(0px,0px,0px);
}
I am seeing the same behavior. It seems iOS9 doesn't want to paint position: fixed elements until AFTER a scroll event has ended.
Example: http://senaeh.de/demo/stickyheaders/simple/
The new sticky header will not show until either the page stops scrolling or the user removes their finger from the screen. Other CSS changes such as background-color work as they should.
This is a regression since iOS8 allowed this completely. Sticky headers are unfortunately not smooth as of ios9.0.1. They still work great on aging Android devices so I'm not sure if this is a bug or if Apple is trying to increase battery life.
EDIT: I filed a bug with Apple (#22902083) so let's hope they make an update to remedy this.
Related
I've created a very basic mdl page and I expect the drawer component to have a variable about of content, almost certainly greater than the height of the page, so it will need to be scrollable. Unfortunately, something about the mdl framework stops the mouse wheel from working on the drawer component. You can even see this in the provided samples such as http://www.getmdl.io/templates/android-dot-com/index.html
I've tried setting the z-index of the drawer div to 999 and other such hacks but it still doesn't seem to work. You can use the scroll bar but that's hardly ideal. It seems to work by default in firefox but not in chrome or IE. Has anyone else dealt with this issue before?
This problem will be fixed with 1.0.6.
Refere https://github.com/google/material-design-lite/pull/1652
I'm facing a problem I can't figure out how to solve. I'm almost sure this is a Chrome bug since in other browsers it works like a charm but I want to be sure. On my website, developed using a mobile first and responsive design approach, I have a menu that uses the Left Nav Flyout pattern. On Tablets and desktops, I show it full width.
When I load the website on my smartphone (specifically an Android device) using Chrome in Portrait mode, once I rotate the device (passing in Landscape mode) and start to scroll the page, as soon as I reach the menu position, the latter magically disappears. What is really strange is that if you try to click the space that now is completely white, you can see that the links are actually there. I tried to use the inspector to find the problem but didn't succeed.
So, wow can I solve the problem? Anyone else had this issue before? If you know it's a bug, I'm glad to add a temporary workaround as well.
I didn't find a real solution but a reasonable workaround. Of course, I still hope that someone will explain what's the cause of this issue and how to solve it.
In the meantime, I found that the problem occurs because the menu, 240px wide, is completely out of the viewport. In fact, as soon as I changed the margin-left to 239.5px the menu didn't disappear anymore.
The left and right buttons for the slider and the small buttons below the slider doesn't work when clicked. only works in IE but not on Firefox and chrome.
Also the images gets out of place when I re-size the browser window to a mobile phone size or tablet size browser.
this is the website http://amakris.com
Thank you
I have been driving myself crazy trying to find an answer to this very problem and I think I just have. It would appear that for the last almost 8 months that Flexslider 2.0 has had a known problem with touch devices. Personally I have an AIO touchscreen and just proved what I found. If you have a touch enabled device and visit any website using flexslider, including Woo's demo - you will notice that by using the "touch" device the slider buttons and navigation work perfectly, but not if you use the mouse.
Apparently there is a touch enabled feature in Chrome which may or may not be able to be turned off or programmed off with a little bit of code. See here: https://github.com/woothemes/FlexSlider/issues/351
It would appear that since flexslider is touch enabled, Chrome and AIO desktops or other touch devices signal to Flexslider to turn off the manual navigation because it is not needed.
I for one am happy that I can stop driving myself crazy now. Enough time has been wasted thinking about this.
I hope anyone else that finds this can rest easy to.
We've run into an optimization problem using WebKit on Mac OS X that we're hoping someone can help us with.
We've written a Cocoa app for Mac OS X that essentially manages a single WebView that points to our online web site. Everything is working fine for the most part. However our web site uses CSS's position:fixed to keep a thin "header bar" locked to the top of the WebView, similar to the big orange "Welcome" bar at the top of StackOverflow.com. We've determined that with position:fixed active, scrolling the WebView forces the entire web page to re-draw itself, which causes scrolling to be agonizingly slow. With position:fixed disabled, scrolling is very fast and fluid; only the page elements that are scrolled "into view" need to be drawn.
We know that this isn't a bug in our Cocoa app code, nor is it a problem with our HTML/CSS code. The same slow scrolling occurs using WebKit test code from Apple. We can point Apple's test code to http://www.StackOverflow.com as a test and we see the exact same behavior. There's also a test page in the Mozilla bug database that we've been using to test the problem (https://bug201307.bugzilla.mozilla.org/attachment.cgi?id=139911). The odd thing is that some WebKit-based browsers on the Mac (eg, Safari and Chrome) don't have this problem; scrolling is always fast on pages using CSS's position:fixed with those two browsers.
Has anyone else experienced this problem with WebKit on OS X? If so, what can we do to speed up our scrolling? Thanks.
I might be way off here as I'm not sure if the same will apply in your web view, but using a style that forces the nav onto its own layer may help.
Something like translateZ(0), or translate3d(0,0,0,). I've come across similar issues when building with Phonegap and applying some thought to layering really helped out.
I believe the browser can utilise hardware acceleration where a third dimension is involved.
I was having a similar problem: the fixed bar was flickering when I was scrolling the page.
So I forced the WebView to use layers and I fixed
[w setWantsLayer:YES];
I had a similar issue in my webview based mac app. It has header and footer with position:fixed css property. Latest webkit shipped with 10.10.x and above don't suffer from this issue. It happens in webkit for mavericks (10.9.x). I got it working by setting these properties for the webview
[self.webView setWantsLayer:YES];
[self.webView setCanDrawSubviewsIntoLayer:YES];
The jQuery time-picker plugin that I wrote uses a div as the containing block for the list of times, and on Mobile Safari there are no scrollbars to indicate that there are more available times than are visible. I know about using two fingers to scroll within the div (on the iPad at least), but that only works if the user knows that there is more content to scroll to, and there's no indication that there is. So, my question: Has anyone been able to get scrollbars to show in Mobile Safari? How'd you do it?
Assuming you are using iOS5.0 or later, I think you have to use the following:
-webkit-overflow-scrolling: auto (this is default style)
auto: One finger scrolling without momentum.
The other available style is
-webkit-overflow-scrolling: touch
touch: Native-style scrolling. Specifying this style has the effect of creating a staking context (like opacity, masks, and transforms).
Using touch mode, the scrollbar will be visible when the user touches and scrolls, but disappear when not in use. If you want to make it always visible, then this old post will help you:
::-webkit-scrollbar {
-webkit-appearance: none;// you need to tweak this to make it available..
width: 8px;
}
Another Piece of Code for Thumb by #BJMC:
::-webkit-scrollbar-thumb {
border-radius: 4px;
background-color: rgba(0,0,0,.5);
box-shadow: 0 0 1px rgba(255,255,255,.5);
}
Original Source
Edit: with respect to this demo's behaviour, you should use jQuery because it will help you a lot, $(document).ready(function(){//your code with timer}) code with timer will need to reset the CSS property to normal after desired time(let's say 5 sec.)
For the demo( that you have described), this is initiated with the onhover event, please check this fiddle I have created for that.
That reproduces the results in a desktop browser, and will also work in iPad, just add your timer code to suit your requirements.
Regarding the original question: the best solution to have scrollbars would be to use an external library (already recommended iScroll is good, but even jQuery UI itself contains scrollbars). But displaying ever-present scrollbars might deviate from the general iOS UI (see below).
Alternative would be to indicate with other GUI elements that the content is scrollable. Consider small gradient fields in the end of the element (the content fades to background there) that suggest that content continues when touched and scrolled.
In iOS5 overflow: scroll functions as expected, i.e it allows the the div to be scrolled up/down with one finger within the area specified by the dimensions of the div. But scrollable div doesn't have scrollbars. This is a bit different from the general UI in iOS(5). Generally there are no scrollbars also, but they appear when user starts scrolling a content area and fade out again after the touch event has stopped.
To answer Sam Hasler comment above.
Nicescroll 3 is a jquery plugin that does just what you want with fade in/out effect and work in all major Mobile/Tablet/Desktop browsers.
Live demo
Code:
$(document).ready(function() {
$("html").niceScroll({styler:"fb",cursorcolor:"#000"});
$("#divexample1").niceScroll();//or styles/options below
$("#divexample2").niceScroll("#wrapperexample2",{cursorcolor:"#0F0",boxzoom:true});
$("#divexample3").niceScroll("#divexample3 iframe",{boxzoom:true});
});
If you want to have the scroll to be always visible,
Do not set -webkit-overflow-scrolling: touch
then set custom style for scrollbar
::-webkit-scrollbar {
-webkit-appearance: none;// you need to tweak this to make it available..
width: 8px;
}
You loss the momentum effect, but scrollbar will always be there.
(tested under iPhone 4/ iOS 7)
Mobile safari, as far as I have seen won't support scrollbars.
The best plugin I could find to get the job done is this.
Its Demos are available here.
It also has multiple predefined skins to suit your application.
here's a sample of what you'll get -
By convention, scrollbars are not used on iOS.
For a div with overflow: scroll, the only native way to scroll is with two fingers.
You might take a look at iScroll, a JavaScript library which handles touch events and implements single-finger momentum scrolling (what users generally expect in native apps) for divs.
until ios5 you could not scroll internal divs - so you probably are not seeing a scroll bar when you try to scroll because there isn't one.
I haven't tested on ios5 but supposedly scrolling internal divs now works.
If it isn't an internal div then you should be able to see the scroll bar when it is scrolling only - this isn't just on ios anymore - lion has gotten rid of all native scroll bars too. You can only see them when a window is scrolling or when the window is first loaded.