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.
Related
I'm developing a website that should run in ancient browsers (IE 7/8/9, Safari 5.1.7). Our target customer is the old people.
I'm no expert in javascript and I searched for solution. My title question is very straight-forward.
I used input radio and others that has custom design using before and after.
If it's checked. I just toggle in after and before display property in css.
The problem is when the user is using ancient browser, the input radio will never appear. My idea is toggle display in input radio if the browser doesn't support pseudo-elements.
For CSS feature detection there really is no need to reinvent the wheel, tools like Modernizr do this perfectly and have a very small footprint, since you can select only the feature detects that you need.
Seeing as you want to support IE <8, I would strongly advise you to use it, since you're probably going to run into a lot of situations where CSS/JS features are unavailable.
Detect if they have a sufficient browser: http://caniuse.com/#feat=css-gencontent
Basically, IE8 (maybe 9 depending on what you need) and older don't work, everything else does.
You may find the library Modernizr useful in this instance. It allows you to test for browser features.
Optionally if you want to shim it so you know that the browser will support it you can use Selectivizr
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)?
I would like to check whether a browser is going to show a special "native" style dropdown (such as the iPhone and iPod) without checking specifically by browser name. Is it possible to check for that capability in a more generic way without looking at the user agent by name?
I'd like to do this to determine whether to render a standard or more enhanced dropdown control.
I don't believe this is actually possible without a really poor solution. I bet the best way to go is to just detect the device because pretty much all mobile browsers use a native ddl for displaying options.
This can be achieved by using Modernizr's media queries and touch detection:
if (Modernizr.touch && Modernizr.mq('only screen and (max-width: 768px)') {
//it is a mobile / tablet device
}
Or use regular CSS media queries.
I'm an 90% sure of this answer: No.
You are looking to detect if you are on a browser that looks weird but you are defining weird subjectively. User Reda's answer is correct, but it violates part of your question (not to identify browsers by name). My point is that you need to identify the browsers by name because you're qualifier is subjective, so you won't find a JS/CSS test for it.
Browsers have complete control over what dropdown they show. Most are inconsistent with their implementation of CSS on these dropdown components. There are no standards saying a browser needs to expose any information about the dropdown at the application level.
To affect what you want, you need to find the browsers whose dropdown controls you don't like and list them out, and target them via Modernizr or other such trickery. Unfortunately that violates your question's intent, so I think the answer to your actual question is... no, sorry.
I'm currently checking for the existence of window.orientation and it seems to do the job for android and ios.
You can check the appearance css property
-webkit-appearance: none;
-moz-appearance: none;
appearance: none;
and if it is not 'none' then your input has native styling.
You can find the possible values of appearance here:
https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-appearance and here http://trentwalton.com/2010/07/14/css-webkit-appearance/
As i read this question i got an idea for a dirty solution. Just a guess but maybe it helps:
Place your native element into the HTML and try get it in JavaScript with the elementFromPoint function. (MDN link)
If you get no element or the returned element is not your native one you know it is not displayed.
try something like this
if (/Android|webOS|iPhone|iPad|iPod|BlackBerry/i.test(navigator.userAgent)) {
$('#SOMEselectpicker').selectpicker('mobile');
}
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'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