I've recently noticed a bug in both my own site, and in other major sites (most notably the Gatsby documentation page). I suspect it's a result of a browser change, but really I have no idea; it might just be a side effect of using something new like Flexbox or CSS Grid.
The bug is simple: the Home key, End key, and UP/DOWN keys don't scroll. The page has scrollbars, and has more content to see ... and you can 100% scroll with a mousewheel or by clicking on the scrollbars and dragging ... but somehow something in the CSS prevents key-based scrolling from working.
You can see the bug here: https://www.gatsbyjs.com/docs/api-reference/. Simply start at the top of the page, and try to use your keyboard to scroll down (even after "clicking into" the right-side part of the page). You can't ... but mouse-based scrolling does continue to work.
My question is not "please debug my problem for me", but rather ... how is this even possible? What CSS styles even have the ability to impact key-based scrolling, separate from mouse-based scrolling?
(And for the record, no, I do not have any Javascript-based onScroll handlers or anything messing things up on my site, and I believe neither does Gatsby's site. Even if you use the developer tools to remove all event listeners, keyboard scrolling remains broken.)
Apparently the answer is "a miscalculated max-height can disable keyboard-based scrolling (but not mouse-based)".
Gatsby's site had the following CSS:
max-height: calc(100vh - 0px - 124px);
(well, it actually had several different ones inside various media queries, but that wasn't relevant).
Evidently the browser didn't like how that calculation resulted, and caused this bug(?). Switching it to a simpler:
max-height: 100%;
corrected the issue.
Obviously this was a very specific case, but if you're having keyboard scroll issues (and not mouse scroll issues), and you're sure Javascript event listeners aren't to blame, it seems max-height (or possibly similar properties like height or max-width) would be the next thing to look at.
In Webkit, will a 3D CSS transform set to repeat indefinitely, continue even when it or a parent element is hidden from view by styling (CSS)?
The reason I ask is that I am seeing unexpectedly high CPU usage on a page I am developing.
If anyone knows a good way to diagnose this issue (for example visualizing where CPU cycles are going on a page, as opposed to a blanket CPU usage per tab), I would be very grateful.
Anecdotal evidence (removal of the hidden CSS animation) would suggest that the animations do run in the background. Does anyone know how to prevent this?
In chrome 16.0.912.75, at least CSS animations appear to continue even when the element is set to visibility:hidden;. Setting display:none appears to resolve the issue.
you can debug this kind of situation with the developer tools
chrome / safari right click inspect element.
Go to the timeline tab and click on record, after that you can see what the browser is doing internally.
I divided page into nonscrollable header and scrollable content. Both are placed as "position:fixed" and content uses "overflow:scroll". This works great, but I noticed that scroll speed changed in Firefox, now mouse wheel scrolls much slower. How can I fix this?
Scroll speed is determined by the browser. CSS and Javascript don't have any way to affect system settings.
Iam assuming that you are concerned about scrolling being not as smooth as you want it to be. There is not much you can do here. The "overflow:scroll" performance will vary across browsers and Iam pretty sure if you check your app in a mobile browser you will find a lot of variation in scrolling speed and smoothness.
The best hack you can do is enable hardware acceleration for browsers where you can encounter this issue with the following css.
-webkit-transform: translateZ(0px);
You should put this property on element which overflow:scroll set.
But this property has its side-effects. It tends to use more memory and may result in crashes.
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.
My Flex application contains a set of Hbox,Vbox combination that is shown/hidden depending on users actions. There is an option provided to show all these containers as open(from their previous hidden state). At that point, the styles used in my page vanishes! The page becomes really lengthy and when I scroll down a bit, the styles reappear. If I scroll up again to a threshold point, all styles are lost and the page looks plain white! To bring the styles back, I need to scroll down again a bit...
Anyone knows why this is happening? Please provide your answers.[EDIT]
Without style http://img268.imageshack.us/img268/1859/withoutstyle.jpg
with style http://img269.imageshack.us/img269/906/withstyle.jpg
The transition from image1 to image2 happens with a mild scroll down!
It sounds like the rendering of the style information is lagging behind the rendering of the data. That's why it 'catches up' if you wait but disappears again if you scroll.