3

Some browsers, notably mobile phone browsers, replace select boxes with native spinner components. Is there a way to detect if the browser uses a spinner or a traditional select?

Nick
  • 10,904
  • 10
  • 49
  • 78
  • 1
    Rendering select elements is totally up to the browser, whether they look "traditional" or not. If you're trying to make this distinction in order to do styling, you may be out of luck: http://stackoverflow.com/questions/12651507/styling-a-select-input-for-ios-first-option-or-initial-state-should-have-smal – Shawn Bush Nov 03 '14 at 22:04
  • 2
    I think it's incorrect to think of this in terms of the browser having "converted" or "replaced" anything. The browser hasn't changed the page or modified the DOM, just like a screen reader doesn't convert or replace anything when it reads the options out loud. The question, then, is: Why do you need to know how the browser is presenting the options to the user? (It's not rhetorical—there are certainly legitimate reasons for wanting to know.) – Jordan Running Nov 03 '14 at 22:04
  • 1
    We've built a better select component than the default in *most* desktop browsers that allows far more flexibility in styling. If the phone or other browser already has a native spinner, we should use that. If not, we replace it dynamically. – Nick Nov 03 '14 at 22:08
  • @Nick then why not apply progressive enhancement, and only apply it on browsers where it is known to improve experience? I'm talking about a white-list of browsers. This means that the native select would be the general case, and your custom one - a special case. – Kos Nov 03 '14 at 22:21

1 Answers1

1

Short answer

You're not supposed to be able to.

Longer answer

When you deliver some HTML content, say:

<h1>Person Dies of Ebola</h1>

You should NOT think about that in the terms of "well, it's an <h1> tag, so the browser will make it bold and larger". That is not what the semantics mean.

<h1> is your way of telling the client browser "hey, this is a header level 1".

The browser may choose to present that to the user in certain ways, but that isn't really something you should rely on when writing your HTML.

When you have a <select> element, you're telling the client that you're about to describe some list of options where the user is expected to choose one.

It happens to be the case that popular browsers implement the interaction functionality for you, but that is not why you write something within a <select>. It's merely the browsers' way of trying to present your content to the client appropriately.

So, if you want to have specific interaction that you wish to implement, use JavaScript. Keep your HTML as is, but write JavaScript that manipulates the DOM and implements the interaction you wish to have.

But, in real terms...

You can probably use user-agent to detect what browser you're on and do stuff accordingly.

Here's a browser detection library that does some of that for you.

Chris
  • 26,544
  • 5
  • 58
  • 71
  • 1
    But if we wanted to make `h1` bold and larger, we could use CSS to do so, and it would be (more or less) consistent across browsers. The problem with some components, especially form components like `select` is that they are resistant to styling. What the browser does based on the semantic meaning of the tag should be up to the browser- until the developer overrides the appearance with CSS. – Nick Nov 03 '14 at 22:14
  • 1
    @Nick right, and you're absolutely correct. ` – Chris Nov 03 '14 at 22:15
  • @Nick now your situation is further complicated because of the fact that you want to not override the native behavior **sometimes**. Like I said, then your best bet is browser detection: [here's a library](https://github.com/ded/bowser). – Chris Nov 03 '14 at 22:16
  • 1
    That's exactly what we did - create a replacement for the native select. It works great on desktop, is fully style-able with proper keyboard support, etc. But we found in testing that in the specific context of mobile phones, the native spinner on those devices is a better choice because it's what users are used to, it's easier to use on touch, and usually is not as hideous as the desktop drop down versions. So i was hoping there would be an easy (read:future proof) way to detect native spinners, but it sounds like that won't be possible. :( – Nick Nov 03 '14 at 22:24
  • @Nick I have a possible solution! Check out [this demo page I threw together](https://chrismatic.io/select/). – Chris Nov 03 '14 at 22:48
  • @Nick you'll see the difference by visiting from desktop vs. spinner-mobile. :) – Chris Nov 03 '14 at 22:48
  • It shows "undefined" on desktop Firefox 30. I don't have a phone at the moment to see what it does. Is this a documented feature or an odd quirk? The Mozilla docs warn not to use the `webkitAppearance` css property on websites, only for XUL (FF extensions). (https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-appearance) I was also thinking of trying `ontouchstart in window` combined with a maximum width to detect phone-like devices. – Nick Nov 04 '14 at 00:51
  • @Nick right, it will give `menulist-button` on mobile devices that replace with a spinner — so you only need check if the value is that. On desktops, it will be `undefined`, `menulist`, or other values that you can simply ignore. – Chris Nov 04 '14 at 00:57