I've got a website that utilizes :hover effects in the navbar & body.
Using the mobile version of Safari on i-devices, hover events become "double-tap" events: one tap to display what would normally appear when 'hovering', and a second tap to 'click' the link. This feature is useful for certain things... displaying a text dropdown on a thumbnail image, for instance, but annoying when selecting a navbar link.
On my android device using Chrome, the opposite occurs by default: Hover effects are simply ignored, no double click, nadda.
How might I modify the default ":hover becomes 'double-click' " behavior for specific objects on mobile versions of safari, while "adding" that functionality for android users?
I don't know the exact setup of your coding, but there are several options you have.
First of all instead of browser or OS detection it is better to use feature detection (if possible), because feature detection will work for every setup instead for specific browsers or OS'. There are some frameworks out there you can use like modernizr.
Another way to deal with things like this is to use CSS Hacks that only apply if it's the specific device/browser/OS. You will find hundreds of CSS Hacks in the net.
There are other ways to detect the browser/OS like the user agent string, for solutions going in this direction I can recommend this question How to detect Safari, Chrome, IE, Firefox and Opera browser? and Detecting iOS / Android Operating system.
What really fits your use case best, you have to decide yourself, but this are the options I suggest.
Related
This is really curious. Interacting with select inputs seems to hide/show address bar based on 'perceived scrolling' by the browser.
I understand the behavior for normal content related page scroll, but it doesn't make sense for the address bar to hide/show based on scroll direction when a select input is being interacted with. This is on ios 15.x and while the example below is on an emulator, the original 'bug' was caught on an actual ios device.
Changing scroll position via JS seemingly does nothing in this case, nor does updating overscroll-behavior or touch-action css attributes on the dom elements.
Here's the behavior in question:
Looks like it is a bug in the iOS 15+ on Safari. There is no issue like that on Chrome.
Nevertheless I've found a workaround for this.
I've made an example, you can test it here. Just open the link on your iOS device. You can find a git repository with the example on my GitHub.
It is not a good practice, it is just a workaround, so there is your choice whether use it or not.
Also, just for your information: I've discussed with other developers who close to me and we have agreed that it is not very good practise to have scrollable element inside scrollable page. On other platforms also might happen some not predictable glitches. it is better to have another UI elements for that if possible.
I want to apply different style if my Multiple select is shown on a mobile device as an iPhone or Android, because it looks ugly. The question is how to detect it:
cannot use media-query for width, cause that may also include desktop browsers
cannot rely on pixel density, cause some tablets also have density>1
not sure if it is enough to just detect mobile browser
I do not want a (jQuery) replacement for <select multiple>, just want to be sure I'm styling one-line-ugly-mobile-ui (and not a desktop version). I do not care if solution is html only, Javascript, css or combination of all.
I have started to use Hammer.js to implement drag functionality for mobile browsers. I have noticed that this functionality also works on desktop browsers (which is confirmed by this compatibility table https://github.com/EightMedia/hammer.js/wiki/Compatibility ).
Are there any drawbacks of using Hammer.js for desktop browsers as well?
As an example; let's say I want to implement a scrollbar (from scratch) where the "thumb" can be dragged. Instead of implementing this using onmousedown/up, onmousemove and set/release mousecapture I can simply use the dragstart, drag and dragend events of Hammer.js.
Hammer.js does a pretty good job on detecting whether it is running on a multitouch enabled system or not.
In most cases it also works pretty well when you have both, a mouse and a touch display. We are developing a desktop web-application based on hammer.js, which should work both, with mouse and multitouch interaction and it mostly works fine. However, it seems that this scenario is not as well tested as the use on mobile devices. See for example this open bug, when hammer.js triggers a tap event twice on Chrome (https://github.com/EightMedia/hammer.js/issues/302) which got closed in between, because no activity was detected.
Note also, that it is often needed to fine tune the behaviour of hammer.js, by fiddling with the user_select, user_drag and prevent_default parameters (see for example this question ). On Google Chrome we also had to enable the experimental touch-actions : none. I do not know, how much of this is specific to desktop systems though.
Summary
Hammer.js is written with desktop systems in mind and does quite a good job in providing sensible behaviour on both mouse and touch based systems. In detail it requires sometime fine tuning to make everything work as expected.
I have a need to create a part of a mobile web page that can scroll on its own (even though I tend to disagree with that being a good thing on mobile). The standard method is to set it to overflow: scroll and there you go.
Alas, on iOS one needs to use two fingers to scroll that area which many still feel is unintuitive. This will be fixed in iOS5, but until then, I need to support it with one touch.
So I found a few JS options. One is Scrollability. The catch is that it only supports iOS. In addition to iOS I need to support android, BlackBerry OS6 and Nokia. So that one is out.
I then tried iScroll. This works pretty well. The catch, for me, is that it does this through pure JS in that you never see a native scrollbar. As such, the scrollbar it generates is more of a dummy in that there's no way to make it work with a mouse or keyboard.
So, the question: Is anyone aware of a JS solution for creating a scrolling div on a mobile web page that a) allows for one-touch scrolling on touch devices and b) uses a native scroll bar to enable keyboard devices?
If there isn't one, we can revert to device detection, giving touch devices the JS and keyboard devices the scrollbar...though that still leaves us the issue of some touch devices also having keyboards.
I was wondering if html5 is supporting touch functionality on a mobile device native? So we don't have to make an native app for iOS/Android/WP7 but can make an html5 page which loads in the mobile browser.
EDIT
I mean the JavaScript support for touch native in the browser so you can do you own thing with the touch in html5.
Depends on the type of touch event. For your standard browser click/mouse events these are emulated by the browser. As mentioned by Halst, just make your clickable elements big enough to work in a mobile environment.
If you want to use multitouch/gestures, it gets a little more interesting.
Webkit provides touchstart, touchmove, touchend, touchcancel. For single touch events support should be the same in both IOS Safari and Android Webkit. You could roll your own or use a library like jqTouch.
You can read more on how IOS Safari handles touch events. Events for Android don't seem to be as well documented, but you can read more on quirksmode touch support.
Just make liks and buttons big enough, and that's it.
Somewhat.
It's possible to write a webpage that looks almost as a native app for iPad (including multi-touch) but I had to give up with using "high level" events and had to handle instead the touches array explicitly to get a reasonable zoom/pan. The results are IMO quite good (people I've shown that vector graphics editor toy thought it was a native app).
For Android however things are a little trickier because on my Nexus one apparently there is no way to get anything close to full-screen (and for a phone losing the address bar space means losing a LOT of space) and also multitouch is disabled in the default browser :-(
Both problems (fullscreen and multitouch) are however solved for example in Opera and this is in my opinion sad because (may be) this means they don't WANT good web apps on the phone...
So technically it's possible to write a single html5/js program that runs in both desktop and phone, but this doesn't of course mean that the best UI for a desktop app is also the best for a phone.