Develop Reference

Detecting whether a browser supports auto-expanding select dropdowns?

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.

How to detect if mobile browser will show a "native" dropdown control?

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');
}

Make Internet Explorer recognize "advanced" CSS selectors

Do any JavaScript libraries exist that somehow make Internet Explorer (no particular version) recognize advanced CSS selectors, such as input[type="text"]?
I hate adding extra classes to HTML objects just to accommodate IE.

I can't believe this wasn't suggested:
http://selectivizr.com/
selectivizr is a JavaScript utility
that emulates CSS3 pseudo-classes and
attribute selectors in Internet
Explorer 6-8. Simply include the
script in your pages and selectivizr
will do the rest.
Selectivizr works automatically so you
don't need any JavaScript knowledge to
use it — you won't even have to modify
your style sheets. Just start writing
CSS3 selectors and they will work in
IE.
You also need to include a standard JavaScript library of your choice, which you're likely already doing.

IE7.js (and IE8.js and IE9.js): http://code.google.com/p/ie7-js/ do their best to bring prior versions of IE up to support for what the script names (e.g. IE8.js tries to make IE6/7 act like IE8). This includes, among other things, many attributes of CSS2/3, though you'll have to check to see exactly what is supported in which version.
if you just want to use the selectors in JS, http://sizzlejs.com/ supports all CSS2/3 selectors and is used as the base for many JS libraries.

so you want a javascript that changes the browsers css support?
i'm pretty sure that's impossible.
your best bet is going to be putting whatever styles you want into a class, and in your document ready, do an .addClass

How can I target jQuery mobile capable phones?

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

JS Test for :target support

I'm writing some code that involves CSS tabs, but IE doesn't support the :target css3 attribute. I have a work around by checking the hash value in an interval (ew), but I want to only have that code run when :target is not supported. I would do the regular IE check, except early versions of Firefox do not support it, nor does early Safari or Opera. Does anyone know how to test for :target support?

You can test for CSS support by adding a rule like #someid:target { visibility:hidden; color:#abcdef; } and then setting the target to #someid, reading if the color is #abcdef, and then reseting the hash.
This will, however, generate entries in the browser history: 1 for when you navigate to the id, and 1 for when you reset it to whatever it was before. It may also create a flicker in your tabs, so that may not be ideal - but I don't know what you can get away with.
Ideally, tabs should ideally read and write the hash for bookmarkability. But I don't think that :target is the ideal solution to creating tabs. I know it looks appealing to begin with (did to me). Given the poor support of the selector, how badly it scales with nested or multiple tabs, and how volatile it becomes with other markup (someone adds a #skip-to link on the page), it is less headache to implement with good old clicks.