I'm working on a website where I have enabled aria-haspopup so it can work on Surface pro. The reason I'm doing that is because the first touch needs to show the css animation and the second touch needs to activate the actual url.
It works great in Edge & IE but I need it to work in Chrome. Are there any javascript alternatives to what I'm trying to accomplish?
Related
I have created my first microsite with Umbraco/ASP.NET at www.surreyhillsmt.co.uk. I started with a bootstrap theme called Agency from startbootstrap.com, and find that the smooth page scrolling from my menu works on the Edge browser and both Safari and Firefox on an iPhone/iPad.
However, smooth page scrolling does not work on either Firefox or Chrome on a PC (fully updated Windows 10, and both Firefox and Chrome installed within last couple of days). This problem is not exhibited by the static bootstrap theme that I used.
I would really appreciate any help. By way of background I am competent with C# and okay with HTML/CSS. I have zero knowledge of javascript and the like.
This is no longer a problem. Oddly this was fixed with the passage of time. I guess it was a caching related issue.
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.
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'm playing around with the bonsai.js library, and I added a big stage to the hero section of my site. However, in Chrome, when the mouse is over the stage (between the tagline and blue button outline), I am unable to scroll down or up. In Firefox and Safari I am still able to scroll. Why is Chrome acting up?
Site: http://cainternet.herokuapp.com
I dont know the bonsai.js library, but probably it is, because the bonsai.js library uses the wheel event and stops it from bubbling in a way, that it only affects chrome. Check the web for "Event Bubbling" for about this topic and check the event usage in your bonsai lib.
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.