I'm making my own little Javascript library that makes it easy to replace the default scrollbars for your Website (and mine) with custom ones. Part of that means giving the BODY element an "overflow:hidden" style to hide the normal scrollbars. However, this prevents all scrolling except for that which is done in code.
I have everything working in terms of showing the bar and having it scroll when you click/drag it. However, many touchpads (like on the computer I'm testing this with) have a feature where you can scroll by sliding a finger along the right side of the pad. I need the library not to break that, so I need some way of detecting when the user tries to scroll this way.
I thought it would be interpreted by the browser as a mouse wheel, so I set up an onmousewheel event, but that doesn't seem to capture it at all. For the record, I'm testing with Firefox 25.0.1.
Is there any way to capture the trackpack scrolling, preferably without an external library? I'm trying to keep this as self-contained and lightweight as possible, but if I absolutely need to, I guess I can use jQuery and its mousewheel extension...
Some browsers use the onwheel event instead of onmousewheel. So, it's usually a good idea to listen for both events.
See this MDN article for more about onwheel.
Related
I want to change the cursor speed inside some div tags, to give a better user experience in my web site. I have already changed the image of the cursor, I want to change slow down the cursor. Is there a way to do that?
I do not think this is possible to control the cursor with Javascript. But you could, however, hide the cursor using
cursor: none;
and then do some JavaScript to emulate a slower moving cursor made with HTML/CSS. But this would be much more work than it is worth, and probably wouldn't work out very well anyway.
Doing this using pure javascript might be a challenge but you can try incorporating this feature slowing down the cursor's speed while holding CTRL using the AutoHotKey script.
You need AutoHotKey installed to perform this but it's free and open-source.
You can't directly control the pointer speed via any DOM API, nor do I expect such an API will become available due to accessibility issues and probable click-jacking abuse.
That being said, in many modern browsers there is an API called Pointer Lock, where you can request control over pointer movements. Using this, you could emulate a slower cursor by taking over the cursor movements and positioning a fake cursor.
I need access to a web-based on screen keyboard which will be used on a touch interface.
This example looks nice and functional, however when I try it on an iPad, the responsiveness it very low IMHO. It's not comfortable to use and sometimes whole words are misspelled due to slow response.
Is there a way to improve the experience on this type of on screen keyboard? This implementation uses the $('#id').click(...); function to process the events. Is there a better way to achieve the goal of typing on the screen? Are there better plugins out there?
Note: The final application will run on different types of devices. For several reasons, native on screen keyboards are no option.
Mobile browsers (iOS specifically, but others too) have a slight delay before triggering the 'click' event so it can differentiate between a single tap and a double tap.
For that style of keyboard you could probably get away with changing the 'click' to a 'mouseup'/'touchend' listener to remove the delay.
However, be aware that you would need to put in extra work if you need to make sure that you only handle a touch/click event if the user presses and releases on the same element (instead of starting the touch on one element and the sliding to another one before releasing).
I've created a website with a parallax street scene. See here for an archived version.
It works just fine on all major desktop browsers, and Safari Mobile. It works fine in Mobile Firefox and Chrome for Android Beta also. However the default Android browser has issues with the scroll event. Let me be clear. Scrolling is not the issue. The div scrolls as required. The scroll event doesn't fire. This issue I experience on Honeycomb as well as ICS.
I'm not concerned about other mobile browsers because for mobile screen sizes one usually does not see the parallax scene; mediaqueries and conditional JavaScript loading take care of that. Responsive design and all that jazz.
Basically, I've written a parallise() jQuery plugin that positions each image based on its position and 'depth'. This function is bound to the scroll event.
On Android Browser, this event only fires at the start of the next touch, instead of continuously.
OK, so I thought that perhaps if I bound the function to touchstart, touchmove, and touchend events I would solve my issue. No cigar. Other touch events are also bugged. Applying the suggested workaround causes the events to fire, but as I have to e.preventDefault(), scrolling (the whole point of the exercise) is disabled.
What if I just poll the position of the stage div relative to the window div? Turns out that the position information is only updated at the start of the next touch.
I am at the end of my tether. Any help would be much appreciated.
Even if the touch events worked correctly on the bugged versions of Android, and you were then effectively able to track the native scroll position during a drag, this would be prone to error. For example, it wouldn't account for the momentum animation which happens after the touching has finished.
iOS and Android make sacrifices to improve the performance of scrolling. On both platforms, it's not possible to get the accurate scroll position until the scroll has completed. The scroll event (on the <body>) doesn't fire until the momentum animation is finished. So while your original question is about scroll events on an overflowing <div>, fixing this might not be totally helpful for you anyway.
If you want an animation to update in time with the scroll, then you need to perform the scroll programatically rather than using the browser's native scroll. The best library to do this is iScroll. You can achieve parallax effects very easily as seen in this demo.
If you need more complex effects (the walking character, in your example), you can opt for the "probe" version of iScroll which allows pixel-perfect polling of scroll position in return for reduced performance.
However, there are many downsides to using iScroll:
You may need to change your markup and styling
It is unnecessary overhead for desktop browsers, but due to markup changes may be difficult to use only as a fallback
The scrolling will not feel perfect - on iOS, with its usually excellent scrolling performance - the slight difference in momentum calculation can feel jarring. On Android, the scrolling can become more laggy than usual.
Swipe shim that doesn't need preventdefault on touchstart: https://github.com/TNT-RoX/android-swipe-shim
I'm using OSX Lion and Chrome which allows you to swipe back and forth to go back/ forward in the browser. However I'm finding it often interferes with scrolling within a page. I have horizontal scroll bars within the website i'm creating and swiping back and forth within them often causes the browser to move forward/ backward in my browse history - definitely not the behaviour i want.
I'm creating my horizontal scroll boxes very simply with html/css and the overflow property. I'm wondering if the correct approach is to use javascript to detect a scroll event, and prevent the default behaviour. It just seems like a more complicated approach to something that should be simple.
http://cubiq.org/iscroll
http://www.azoffdesign.com/plugins/js/overscroll
http://uxebu.com/blog/2010/09/15/touchscroll-0-2-first-alpha-available/
http://plugins.jquery.com/project/jScrollTouch
Tried or seen any of these, you can just disable the browser scrollbars and use these instead..
I've got a website that provides labels when the user hovers over an image. You can see the example at: http://www.185vfx.com/
For touchscreens, I'd like to have those hints on by default (since hover isn't usually available). I'd prefer not to browser-sniff and try to maintain that list as new devices/versions arrive.
Any reliable way to detect if a browser can respond to hover or otherwise know about a touchscreen user via javascript or css?
No.
Even if they do have a touchscreen, they might be using a mouse anyway. For that matter, whether they have a touchscreen or not, they might be using a keyboard (or a breath switch or something else) to navigate and still be unable to hover.
It is best not to put important information behind a hover reveal in the first place (or at least to always provide another means to access it).