I recently realized that the checkboxes take really long to respond to tapping. I am already using fastclick.js to remove the 300ms slowness caused by mobile devices waiting for double tapping.
I noticed that jQuery mobile uses some kind of technique to completely remove the lag when tapping multiple checkboxes very quickly. From what I have read elsewhere there seems to be a problem with mobiles when using click events rather than tap events, but haven't been able to find code to achieve this anywhere.
I would use a custom jQuery mobile build to take advantage of this, but what I am working on is already too heavy, so having the code that replaces click with tap for mobile, I would be really grateful!
The best approach is to use a library that handles touch events. There are many including these:
Hammer.js - 3kb gzipped
Zepto.js - 9.2kb gzipped
Quojs - 6kb gzipped
jGestures
Zepto is like a mini-jQuery and does a lot more than touch events, however it is designed in nice modules, one of which is the touch events module. One option if you don't want to include an entire library and you are using jQuery is to only include the touch module from zepto. Try using this code from github taking care to replace the last line from })(Zepto) to })(jQuery) and it should just work.
Some googling found this related SO question, with some good answers:
How to use jQuery Mobile for its touch event support only (no UI enhancements)?
Related
In IE 6/7/8 a <select> element, if given a defined width, does not automatically expand once opened. With browser sniffing (jQuery example was to use $.browser.msie and $.browser.version) I could detect the current browser to a degree of certainty and, for the relevant browsers add in a custom handler for selects.
In jQuery 1.9 the $.browser object has been removed. I am still using an older version in production, and am able to browser sniff and show auto-expanding select menus accordingly; However, this isn't a long term solution if we're going to keep up with the later releases of jQuery.
I've had a look through the properties of select via for(var i in document.createElement('select')) { ... } but can't see anything obvious relating to whether or not the menu will automatically expand.
Is there such a thing? Ideally, I'm looking for a vanilla solution that doesn't require browser sniffing. An if(!property in document.createElement('select')) { ... } would be fantastic.
[Edit / Addition] I know about jQuery migrate and understand it will probably tide us over. I'm not overly keen to load in more things for one (at the moment) tiny inconvenience.
From the jQuery API of jQuery.browser:
We recommend against using this property; please try to use feature
detection instead (see jQuery.support). jQuery.browser may be moved to
a plugin in a future release of jQuery.
I investigated and found the jQuery Migrate Plugin which has the $.browser feature, the code is available at github.
I have a page that plays an mp3 file when button pressed, using javascript like:
onclick="playAudio"
There is the obvious 300ms delay. I want to use this through html5 browsers only, using the nexus 7 only. So I dont want any backup code for IE6 etc. Every solution I've seen seems quite complicated and I can't get it to work.
Is there no simple javascript solution?
Check out the Fastclick project on github. If I understand your question, you just want to get rid of the 300ms delay on touch devices. This project is a polyfill to make touch uis much more snappy and responsive. Here is the url:
https://github.com/ftlabs/fastclick
Use Case:
Just include the fastclick library like so:
<script type='application/javascript' src='/path/to/fastclick.js'></script>
And then just instantiate it by putting following in your main app js file:
window.addEventListener('load', function() {
new FastClick(document.body);
}, false);
Hope that helps!
As I understand your question, this problem is related to playing audio and not necessarily related to interaction with buttons. So, on the basis of that I will try to answer your question in the following.
I assume you are using the HTML5 audio API for this. Have you taken a look at the preload attribute? It has a value called auto which tells the browser that it might be a good idea to preload the audio. The drawback of this is that you risk to cause unnecessary overhead to the server since you are almost always downloading the audio no matter what. Using this approach you can, through JavaScript, subscribe to an canplaythrough event, telling you when the audio has been downloaded and is ready to be played.
More details on this subject can be found here:
http://blogs.msdn.com/b/ie/archive/2011/05/13/unlocking-the-power-of-html5-lt-audio-gt.aspx
https://developer.mozilla.org/en-US/docs/HTML/Element/audio
I'm looking for some combination of a plugin or clever programming technique that will allow me to have a context-style menu in jQuery but rather than actually triggering it from a right-click, I'd like to be able to have it triggered from a button that can potentially move to different locations on my window. I can handle the part of the button itself moving without much trouble. My requirements are:
It should be compatible with jQuery UI 1.8 and my custom themeroller-generated theme
It needs to be relocatable
I either need to have it execute a callback when an element is selected, or have it honor the href on any a tags that make up the menu elements
I looked at Selectmenu and it's close, but it seems to want to always show the currently selected item, which is not quite what I want. Also I had to hack around it in an ugly way to make it relocate properly.
This blog post is also pretty close but the jsEvent.clientX and jsEvent.clientY don't put the dialog in the right place and I'm a little stuck as to what to do about that. Also I don't really want the options to be buttons. The menu-ish plugins have them looking right.
This plugin here is pretty much exactly what I want (I'd have to add the bit about the button, but it doesn't look too hard). But that requires jQuery UI 1.9.
Any thoughts? It may be that this is just such a rare requirement that I have to roll my own, but somehow that seems surprising and I feel like I might be missing something.
I like this plugin. It seems that is more compatible than jQueryUI-contextmenu.
Is a fork of jQueryUI-contextmenu actually
jQuery-contextMenu
I liked it because it has more examples, and it says that only use one footprint in memory so it consume less resources in comparison to others. Works with +jquery 1.6 and don't necessarily need html markup,
The menu plugin you mentioned last seems to work fine with jQuery UI 1.8.x, but not jQuery UI 1.7.x.
jQ-UI 1.8.7: http://jsfiddle.net/william/xxGUW/
jQ-UI 1.8.9: http://jsfiddle.net/william/xxGUW/1/
jQ-UI 1.8.14: http://jsfiddle.net/william/xxGUW/2/
jQ-UI 1.7.2 (broken): http://jsfiddle.net/william/xxGUW/3/
I was playing around with JavaScript a little while ago, and it irritated me that I couldn't create my own event.
I've seen Framework's with this built in (jQuery, MooTools, Prototype. Dojo doesn't which is weird because it seems to do everything and your laundry) and I actually built my own system for creating and firing custom events.
It just feels like there should be a native way to do it. Does anyone know how to do this/if you even can?
var dragEvent = document.createEvent("Event");
dragEvent.initEvent("dragged", true, true);
el.dispatchEvent(dragEvent);
For official specs, see DOM Level 2 Events. See also createEvent(), initEvent() / initMouseEvent() / initUIEvent(), and dispatchEvent() at MDC.
I use this technique to create custom drag and resize events for communication on this sample page.
I've made a web-app using the jQuery Mobile framework for which I would like to provide a fall-back, for lower-spec phones.
My question is... what is the best way to target JQM-capablephones? I saw a similar question posted on the jquery forum. One of the answers suggested http://detectmobilebrowser.com/ which provides a long list of handsets.
Is this the best way, or should I be testing for browser-capabilities rather than actually targeting handsets. If it is the latter what feaures are considered to be 'Grade-A' featues?
Cheers
Progressive enhancement is what you should aim for, jQuery allows you to have a single codebase and have it work across the range of devices.
Consider this:
All links to other pages are regular html links, links will still work without AJAX support because they'd just send you to the location of the required page
All major framework elements are built around lists, links, and a few divs. No HTML5 required for rendering content
At the bare minimum, all phones can display a good amount of styling, allowing you to display the content no matter how capable
Do you have custom interfaces which wouldn't work at all without full support for jQuery mobile?
I agree that graceful degradation is the best solution. I would add that using the noscript tags is also a good way to provide graceful degradation by adding adding functionality via HTML for phones that have no support for JS.
I think it will be difficult to find a browser-capability (or even a set) that defines whether the phone will work with JQM. In my own experience I have used WURFL, an open source device detection library, that provides capability information. However I used it to target specific devices to include device specific CSS and remove all JS for other devices that I know do not support it (to remove the overhead of the JS being downloaded).
WURFL: http://wurfl.sourceforge.net/
JQM advertises that it provides graceful degradation:
Graceful Degradation: jQuery Mobile uses the very best HTML 5 and CSS 3 features to provide the best possible experience in the most-capable browsers. However we don’t consider this to be an all-or-nothing proposition: Less capable browsers will still receive the best possible experience that their platform can handle. They may not have all the gradients or fancy transitions of the best platforms but they’ll still be highly usable. The most basic browsers will easily degrade back to simplified HTML and CSS.
I have also tested multiple JQM pages in a single mobile page which work great (very speedy) in JQM but suffer from the same problem mentioned (all pages show up when javascript is turned off in the browser of a smart phone). To work around this issue, only use a single page per JQM page (you give up speed and uniform page transitioning though). In regards to the NOSCRIPT tag option, that tag is NOT universally recognized in all browsers. To work around that issue, you could try something like the following:
<div id="no-js">
<!-- Place HTML without javascript here -->
</div>
<div id="js">
<script language="javascript">
// place javascript here which would be ignored by browsers not support javascript or with
// javascript turned off
document.getElementById("no-js").style.display = "none"; // be sure to hide the non javascript
// div
</script>
</div>
The above logic would work in either NOSCRIPT tag type browsers as well as those that do not recognize NOSCRIPT.
dlausch