When incorporating an <input type="range"> slider into a form (ie, Best form element to indicate level of completeness of a task?), Firefox degrades not-so-gracefully to a text box.

Chrome vs. Firefox on <input type="range">

Since we need to show the form options semantically, as in the linked example above, Firefox's degrading won't work here.

What are some options for nicer degrading? Of the two solutions below, which is better? or are there better solutions?

  1. jQuery UI (http://jqueryui.com/demos/slider/)
  2. Range polyfill (http://jsbin.com/atocep/32/edit) that will convert select inputs into ranges for those browsers that support <input type="range">
  • 1
    What are your criteria for the "better" solution? If the controls look & behave the same in all browsers then the points of differentiation would be performance (i.e. loading & execution times) and accessibility.
    – dnbrv
    Commented Mar 25, 2012 at 3:50
  • Right, there are trade-offs with each option, and the real question is is it worth it to load the UI at the expense of speed & performance for just one component of the form. Option 1 would allow a slider across all browsers, but at the expense of the added weight of loading the jQuery UI and then perhaps needlessly (ie Chrome) rendering a range input. Option 2 is less bulky, but would not render a range input for a huge chunk of users. Commented Mar 25, 2012 at 7:35

2 Answers 2


Why don't you use compatibility check library like Modernizr


Than based on your detection, decide what you load, so that newer browsers get the HTML5 goodies and all the rest get to work with jQuery UI.


It depends! If your entire loading time of the page within the process stays within a second, I would recommend to implement similar controls of the web page. Your image of Firefox implementing the range input is really bad, and if it can be avoided it should.

Jacob Nielsen, a usability guru, wrote an article of Response time limits on applications and web applications saying:

0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it's selected. Ideally, this would also be the response time for sorting the column - if so, users would feel that they are sorting the table.

1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2-1.0 seconds does mean that users notice the delay and thus feel the computer is "working" on the command, as opposed to having the command be a direct effect of the users' actions. Example: If sorting a table according to the selected column can't be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of "flow" in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.

10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user's work, for example when switching tasks.

Good Luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.